ADO + Excel

← →
MacroDenS © (2011-06-20 12:13) [0]

Доброго времени суток.

Возникла такая ситуация,
подключаюсь к Excel файлу через DSN + ADO.
На форме ADOConnection, ADOQuery, DataSource и DBGrid.
Данные получаю через sql запрос
select * from [Лист1$]
В таблице в заголовках присутствуют текстовые значения "дата операции", "дата отправления" и т.д
Так вот при выполнении запроса, в DBGrid"е названия полей со словом "дата" перестают отображаться. При попытке вручную в гриде прописать "дата операции" вываливается сообщение econverterror with message "Дата"...

Подскажите пожалуйста, почему ADO (если это он) так реагирует на слово "дата" и как убрать такую реакцию.

Заменить слово "дата" на что нибудь другое не вариант.

Заранее спасибо.

← →
sniknik © (2011-06-20 13:06) [1]

не знаю насчет "дата", но вот это
> econverterror with message "Дата"...
означает неверный тип, при конвертации... т.е. вместо строки "Дата" возможно ждет что-то типа 125,34.

← →
macrodens © (2011-06-20 13:10) [2]

Да это я понял, что он ожидает определенный тип даты.
---
Кстати подобная реакция еще наблюдается если в ячейке предпологаемого заголока находится слово "количество" и "вес".

← →
sniknik © (2011-06-20 13:14) [3]

> ожидает определенный тип даты.
тип определяется по первым 8 значениям (по умолчанию), можно поставить больше (в реестре), или читать все как строки (в строке соединения указать, не помню правда параметров... поищи)

← →
Anatoly Podgoretsky © (2011-06-20 13:28) [4]

> MacroDenS (20.06.2011 12:13:00) [0]

Не используй звездочку

← →
macrodens © (2011-06-20 13:35) [5]

Anatoly Podgoretsky © (20.06.11 13:28) [4]

А мне заранее не известесно сколько там будет полей, в каком порядке они будут и с какими названиями.

← →
macrodens © (2011-06-20 14:07) [6]

Все разобрался, пришлось ConnectionString немного по другому построить, без использования DSN + IMEX.

Все спасибо.

← →
Anatoly Podgoretsky © (2011-06-20 14:25) [7]

> А мне заранее не известесно сколько там будет полей, в каком
> порядке они будут и с какими названиями.

Как же ты собираешься работать неизвестно с чем?

ODBC это бяка

← →
macrodens © (2011-06-20 15:03) [8]

Как же ты собираешься работать неизвестно с чем?

Да вот так приходится...
Задача из кучи excel файлов с различными структурами данных формировать базу.
Слава богу переодически структуры могут повторяться.
Выход: юзер по каждой новой структуре создает определенный шаблон привязки колонок в excel файле с нужными полями в БД. после чего будет происходить загрузка в БД.
Пробовал лезть в Excel через OLE - но это очень медленно получается.
Поэтому выбрал ODBC, хоть он и бяка...

← →
sniknik © (2011-06-20 15:23) [9]

> Пробовал лезть в Excel через OLE - но это очень медленно получается.
> Поэтому выбрал ODBC, хоть он и бяка...
вдвойне бяка... т.к. работает не сам, а используя тот же самый OLE DB

для примера, подключаемся
Provider=MSDASQL.1;Persist Security Info=False;Data Source=Файлы Excel

делаем запрос к заведомо несуществующей базе...
SELECT * FROM [Данные$] IN "D:\Test.xls" "Excel 8.0;"

получаем ошибку
EOleException : [Microsoft][Драйвер ODBC Excel] Объект "Данные$" не найден ядром базы данных Microsoft Jet. Проверьте существование объекта и правильность имени и пути

чешем репу. почему быстрее?

← →
macrodens © (2011-06-20 16:00) [10]

Я делал раньше через CreateOLEObject("Excel.Application"), а это загружает таки Excel и работает через него, отсюда и скорось не очень высокая.
В данном случае через OLD DB намного быстрее,
К сравнению,
Вариант 1.
Создаем экземпляр Excel, загружает в него нужный файл, считываеам значения ячеек конкретной строки.
Выполняется за ~4028,7 ms.
Вариант 2.
Подключаюсь к файлу через ADO, устанавливаю номер конкретной записи в Датасете, считываю
Выполняется за ~120,5 ms
Итого: ADO в ~33 раза быстрее.

← →
sniknik © (2011-06-20 16:20) [11]

> Выполняется за ~120,5 ms
> Итого: ADO в ~33 раза быстрее.
а в попугаях длиннее, а у слона толще...

только какое отношение имеет то как ты это делаешь, и как ты это называешь, к словам

> ODBC это бяка
и дальнейшему
> Да вот так приходится...
> ...
> Пробовал лезть в Excel через OLE - но это очень медленно получается.
> Поэтому выбрал ODBC, хоть он и бяка...

> Создаем экземпляр Excel
это ActivX

> Поэтому выбрал ODBC, хоть он и бяка...

А нафига? Лезть надо через JET

> Создаем экземпляр Excel это ActivX

А ActiveX по твоему это не OLE?

Тот же COM/OLE под другим названием.

> Поэтому выбрал ODBC, хоть он и бяка...
это просто ответ к посту [7].

А нафига? Лезть надо через JET
Через JET - это как (просто не задавался таким вопросом ранее)

> macrodens (20.06.2011 16:49:13) [13]

> А ActiveX по твоему это не OLE?

Только это уже другой DOM

> А ActiveX по твоему это не OLE?
OLE 2.0 если быть точным, переименовано давным давно дабы не путать...

> Тот же COM/OLE под другим названием.
ага. давай тогда мой велосипед на твою машину поменяем... ну, это тоже самое транспортное средство под другим названием...

немного не корректное сравнение при OLE машина ехала только в перед, с
ActiveX еще в стороны стала поворачивать, задний ход сделали, да и двери стали открываться...

ага. давай тогда мой велосипед на твою машину поменяем
ой как рискуешь в таком случае...

А это в тему к технологиям COM/OLE/ActiveX & etc
http://lurkmore.ru/%D0%A4%D0%B0%D1%82%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9_%D0%BD%D0%B5%D0%B4%D0%BE%D1%81%D1%82%D0%B0%D1%82%D0%BE%D0%BA

ADO + Excel Найти похожие ветки