Developing.ru

Уважаемые ,
Появилась необходимость вывести результат большого SQL (из Query) запроса в файлик EXCEL , сделал через Insert в Opendatasorce , но что-то не нравится (апдейта нету) Пытался делать запрос к источнику данных, но там в поле мне нехватает места под текст моего запроса. Подскажите как сделать ?

1) Можно сделать чтобы сам EXCEL проселектил чего надо на лист.
2) Наверняка в самой базе есть инструменты экспорта в текстовые файлы (csv), так Еxcel их открывает. Кстати, база-то какая?!

PS
Если под "большим SQL" имелся в виду размер результата, то в Excel влазит 65536 записей на лист, что можно считать сравнительно небольшим набором.

Посмотри на MS Query. Он поставляется вместе с Excel'ем.

Naeel Maqsudov писал(а):1) Можно сделать чтобы сам EXCEL проселектил чего надо на лист.
2) Наверняка в самой базе есть инструменты экспорта в текстовые файлы (csv), так Еxcel их открывает. Кстати, база-то какая?!

PS
Если под "большим SQL" имелся в виду размер результата, то в Excel влазит 65536 записей на лист, что можно считать сравнительно небольшим набором.

1) По большим запросом SQL , я имею в виду большой запрос а не большой результат, результат может быть в 3 строки, а вот отбор этого результата занимает пару-тройку страниц.

2) Каким образом можно заставить Excel самому проселектить таким большим запросом ?

3) Сохранить выборку руками я и так могу в любой формат (CSV например), мне необходимо чтобы инфа в Excel попала сама после отработки скрипта.

4) База - обычная база данных на MSSQL, запрос запускаю в Query Analyzer .

5) MS Query не умеет отрабатывать OPENDATASOURCE

Тогда используйте хранимый запрос (view).

Пусть Ваш длинный-предлинный запрос хранится на сервере, а
select * from этот_запрос
будет уже достаточно коротким, чтобы исполнить его через MS Query

Если запрос формируется динамически, то надо копать в сторону параметризованных запросов, а в крайнем случае - в сторону хранимых процедур.

Naeel Maqsudov писал(а):Тогда используйте хранимый запрос (view).

Пусть Ваш длинный-предлинный запрос хранится на сервере, а
select * from этот_запрос
будет уже достаточно коротким, чтобы исполнить его через MS Query

Если запрос формируется динамически, то надо копать в сторону параметризованных запросов, а в крайнем случае - в сторону хранимых процедур.

Вот спасибо мил человек за мысль про вьюхи(решил с помощью них другую проблему), а первоначальную через вью не решить, потому как в запросе и процедуры и временные таблицы и чего только нет.

Значит вместо view надо создавать хранимую процедуру, возвращающую набор записей. (не знаю как они называются в MSSQL) Из таких процедур можно селектить, как из таблиц. В конце-концов View и хранимые PLSQL-процедуры для того и придумали, чтобы всу сложную логику работы с данными изолировать от клиентских приложений.

PS
Так как вполне возможно, что ограничение в MS Query накладывается не самим MS Query, а, например, ODBC. А это значит, что и у других клиентскиих приложений могут быть проблемы в будущем.