| 
| 
 | Вопрос # 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
 
 |  
 Мини-форум вопросаМини-форум пуст. Чтобы оставлять сообщения в мини-форумах, Вы должны авторизироваться на сайте. |