Конференция "Базы" » ADO + Excel [D7, Excel]
 
  • MacroDenS © (20.06.11 12:13) [0]
    Доброго времени суток.

    Возникла такая ситуация,
    подключаюсь к Excel файлу через DSN + ADO.
    На форме ADOConnection, ADOQuery, DataSource и DBGrid.
    Данные получаю через sql запрос
    select * from [Лист1$]


    В таблице в заголовках присутствуют текстовые значения "дата операции", "дата отправления" и т.д
    Так вот при выполнении запроса, в DBGrid'е названия полей со словом "дата" перестают отображаться. При попытке вручную в гриде прописать "дата операции" вываливается сообщение econverterror with message 'Дата'...

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

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

    Заранее спасибо.
  • sniknik © (20.06.11 13:06) [1]
    не знаю насчет "дата", но вот это
    > econverterror with message 'Дата'...
    означает неверный тип, при конвертации... т.е. вместо строки 'Дата' возможно ждет что-то типа 125,34.
  • macrodens © (20.06.11 13:10) [2]
    Да это я понял, что он ожидает определенный тип даты.
    ---
    Кстати подобная реакция еще наблюдается если в ячейке предпологаемого заголока находится слово "количество" и "вес".
  • sniknik © (20.06.11 13:14) [3]
    > ожидает определенный тип даты.
    тип определяется по первым 8 значениям (по умолчанию), можно поставить больше (в реестре), или читать все как строки (в строке соединения указать, не помню правда параметров... поищи)
  • Anatoly Podgoretsky © (20.06.11 13:28) [4]
    > MacroDenS  (20.06.2011 12:13:00)  [0]

    Не используй звездочку
  • macrodens © (20.06.11 13:35) [5]
    Anatoly Podgoretsky ©   (20.06.11 13:28) [4]

    А мне заранее не известесно сколько там будет полей, в каком порядке они будут и с какими названиями.
  • macrodens © (20.06.11 14:07) [6]
    Все разобрался, пришлось ConnectionString немного по другому построить, без использования DSN + IMEX.

    Все спасибо.
  • Anatoly Podgoretsky © (20.06.11 14:25) [7]

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

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

    ODBC это бяка
  • macrodens © (20.06.11 15:03) [8]
    Как же ты собираешься работать неизвестно с чем?

    Да вот так приходится...
    Задача из кучи excel файлов с различными структурами данных формировать базу.
    Слава богу переодически структуры могут повторяться.
    Выход: юзер по каждой новой структуре создает определенный шаблон привязки колонок в excel файле с нужными полями в БД. после чего будет происходить загрузка в БД.
    Пробовал лезть в Excel через OLE - но это очень медленно получается.
    Поэтому выбрал ODBC, хоть он и бяка...
  • sniknik © (20.06.11 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 © (20.06.11 16:00) [10]
    Я делал раньше через CreateOLEObject('Excel.Application'), а это загружает таки Excel и работает через него, отсюда и скорось не очень высокая.
    В данном случае через OLD DB намного быстрее,
    К сравнению,
    Вариант 1.
    Создаем экземпляр Excel, загружает в него нужный файл, считываеам значения ячеек конкретной строки.
    Выполняется за ~4028,7 ms.
    Вариант 2.
    Подключаюсь к файлу через ADO, устанавливаю номер конкретной записи в Датасете, считываю
    Выполняется за ~120,5 ms
    Итого: ADO в ~33 раза быстрее.
  • sniknik © (20.06.11 16:20) [11]
    > Выполняется за ~120,5 ms
    > Итого: ADO в ~33 раза быстрее.
    а в попугаях длиннее, а у слона толще...  

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

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

    > Создаем экземпляр Excel
    это ActivX
  • Anatoly Podgoretsky © (20.06.11 16:27) [12]

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

    А нафига? Лезть надо через JET
  • macrodens © (20.06.11 16:49) [13]
    > Создаем экземпляр Excel это ActivX

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

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

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

    А нафига? Лезть надо через JET
    Через JET - это как (просто не задавался таким вопросом ранее)
  • Anatoly Podgoretsky © (20.06.11 16:56) [14]
    > macrodens  (20.06.2011 16:49:13)  [13]

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

    Только это уже другой DOM
  • sniknik © (20.06.11 16:56) [15]
    > А ActiveX по твоему это не OLE?
    OLE 2.0 если быть точным, переименовано давным давно дабы не путать...

    > Тот же COM/OLE под другим названием.
    ага. давай тогда мой велосипед на твою машину поменяем... ну, это тоже самое транспортное средство под другим названием...
  • macrodens © (20.06.11 17:06) [16]
    немного не корректное сравнение при 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 [D7, Excel]
Есть новые Нет новых   [134431   +10][b:0][p:0.001]