|
Вопрос # 1 994/ вопрос открыт / |
|
Здравствуйте, эксперты! Можно ли экспортировать данные из DBGrid в формат MS Excel с расширением *.csv ? Если да, то как?
 |
Вопрос задал: alone (статус: Посетитель)
Вопрос отправлен: 14 октября 2008, 00:09
Состояние вопроса: открыт, ответов: 2.
|
Ответ #1. Отвечает эксперт: Вадим К
Здравствуйте, Гадлевский Олег Вячеславович!
Не знаю, сколько ещё буду писать. DBGrid не хранит информацию, поэтому единственный и правильный ответ на Ваш вопрос - никак.
Но на самом деле всё гораздо проще. С этим гридом должен быть связан какой нибуть Table или Query
В таком случае код будет где то таким (грубый набросок, который надо будет дотачивать напильником под Ваши потребности).
var sl:TStringList;
begin
sl := TStringList.create;
try
Table.first;
while not table.eof do begin
sl.add(table.fieldbyname('pole1')+','+table.fieldbyname('pole2')+','+table.fieldbyname('pole3')+');
Table.next;
end;
sl.saveToFile('MyFile.cvs');
finally
sl.free;
end;
end;
А теперь коментарии-замечания.
- строковые поля, которые теоретически могут иметь пробелы и запятые надо заключать в двойные кавычки
- порядок полей в строке зависит от вашей фантазии. можно даже на лету делать переформатирование (ну например число от 0 до 7 переводить в дни недели)
- вместо запятой разделителем может быть почти всё что угодно, например точка с запятой
- сам TStringList позволят формировать такие строки, но это замедляет работу, особенно на больших объемах.
- при очень огромных размерах рекомендуется TStringList заменить на TStringStream
- Если Table (а это может быть и Query, и ADOTable и любой другой компонент), то настоятельно рекомендуюется не подключать его к DBGrid Или на момент экспорта отключать. Иначе тормоза будут заметны уже на маленьких объемах. Ещё лучше - иметь для этого дела отдельный компонент.
- в случае ADO очень удобно юзать _RecordSet + ADOCommand. Получается очень красиво и быстро.
- Теоретически, никто на запрещает прямо в цикле отфильтровывать лишние записи - просто не добавлять, если не попадают под условие, но лучше это делать с помощью правильного SQL запроса - как минимум будет работать быстрее, запрос проще править, проще подгрузить с другого места (один и тот же код будет обрабатывать различные запросы) и просто получить одобрение от более опытных программистов. В случае серверных СУБД (когда сервер стоит на отдельном сервере) можно получить просто невероятное ускорение - представьте себе, что на сервере миллионы записей, а надо пара десятков. Плюс админ сети/сервера скажет спасиба.
 |
Ответ отправил: Вадим К (статус: Академик)
Время отправки: 14 октября 2008, 02:47
Оценка за ответ: 5
Комментарий к оценке: Спасибо огромное
|
Ответ #2. Отвечает эксперт: Feniks
Здравствуйте, Гадлевский Олег Вячеславович!
Немного дополню. Раз уж вы заговорили про экспорт в Excel, то я выскажу свое "фее".
Лучше, на мой взгляд, использовать сторонние библиотеки и компоненты для работы с Excel на прямую, без использования OLE объектов. Работа через OLE очень тормазнутая, особенно это ощутимо на больших таблицах, плюс использование форматирование ячеек. В добавок, обязывает обязательное наличие самого MS Office. Ведь если его нет, то и объектов нет, а значит ваша программа не сможет выполнить данные инструкции.
Попробуйте использовать компоненты с нашего сайта, я думаю вам понравится и вы ощутите разницу:
1. XLSReadWrite - мощный компонент для работы с файлами "*.xls".
2. vtkExport - библиотека, предназначенная для экспорта данных из Ваших программ в форматы Excel и HTML.
Формирование XLS файла происходит без использования DDE, OLE, т.е. для того, чтобы получить XLS-файл, не обязательно, чтобы на компьютере был установлен Excel. Метод экспорта очень прост - Вы формируете объект TvteXLSWorkBook, который имеет свойства и методы схожие со свойствами и методами OLE сервера Excel и вызываете у него метод SaveAsXLSToFile или SaveAsHTMLToFile.
Лично я пользовался vtkExport и был очень доволен, т.к. приходилось экпортировать большие таблицы лет 5 назад. Тогда еще не было таких современных и мощных компьютеров, и экспорт таблиц через OLE занимал времени более 20 минут. Это приемлемо, если вы в течении дня одну, две таблицы обрабатываете. Но когда вам надо десятки таблиц в течении пару часов, то сами понимаете, какого это...
А vtkExport мне таблички кидал менее чем за 30-40 секунд.
Так что, пробуйте и делайте выводы.
Ну а если же Вы отважились использовать стандартные компоненты в Delphi, которые работают через OLE, то рекомендую сначало почитать мою статейку "Delphi 4: Автоматизация приложений MSR Office для эффективного анализа результатов. Глава 1. Работа с MS Excel."
P.S. Жедаю удачи.
 |
Ответ отправил: Feniks (статус: Бакалавр)
Время отправки: 20 октября 2008, 15:52
|
Мини-форум вопроса
Мини-форум пуст.
Чтобы оставлять сообщения в мини-форумах, Вы должны авторизироваться на сайте.
|