ADO и DBF - вопросы

Работа VB и СУБД (Access, MSSQL, MySQL, Oracle и пр.)
Правила форума
При создании новой темы не забывайте указывать используемую СУБД.
alibek
Большой Человек
Большой Человек
 
Сообщения: 14205
Зарегистрирован: 19.04.2002 (Пт) 11:40
Откуда: Russia

ADO и DBF - вопросы

Сообщение alibek » 11.02.2005 (Пт) 21:58

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

Возник такой вопрос. Сейчас делаю в программе функцию обновления справочника адресов из КЛАДР (классификатор адресов, распространяемый ГНИ).
Справочник представляет собой DBF-файлы с кодировкой CP1251 (Visual FoxPro). Нашел две строки подключения,
"Provider=vfpoledb.1;Data Source=<path>;Collating Sequence=general"
и
"Driver={Microsoft Visual FoxPro Driver};SourceType=DBF;SourceDB=<path>;Exclusive=No;Collate=Machine;NULL=NO;DELETED=NO;BACKGROUNDFETCH=NO".

Вначале использовал ODBC (т.к. OLEDB провайдер есть не на всех машинах, его устанавливать надо отдельно).
Все работало замечательно, асинхронность есть, кодировки не глючат, даже объединение таблиц есть (я объединяю элементы с базой сокращений, т.к. у меня используются свои собственные сокращения; т.е. я получаю полное наименование, а потом по нему уже ищу в своей таблице новое сокращение).
Проблема подкралась неожиданно.
В КЛАДР довольно дурацкая система кодирования. Т.е. есть 11-значный код для населенных пунктов, районов и областей и 15-значный код для улиц. При этом первые два разряда идентифицируют области, следующие 3 районы, следующие 3 города, следующие три населенные пункты (поселки и пр.) и последние четыре улицу. Т.е. если мне надо отобрать из всего списка только области, нужен такой фильтр:
CODE Like '__000000000'
или же
Mid$([CODE];2;9) = '000000000'

Так вот, ни один из этих вариантов не работает. Первый глючит с регулярными выражениями и всегда возвращает пустой рекордсет (пробовал и % и * и ?, без разницы). Второй тоже не работает, потому что ODBC-драйвер не знает таких функций, как Left$(), Mid$(), Right$().


После этого поставил OLEDB-провайдер. Но и тут засада. Запросы отрабатывают правильно, но теперь нет асинхронности. Т.е. запрос отрабатывает вроде бы асинхронно, но события не происходит вообще никакого. Скачал с сайта девятую версию, но в ней нет ни примеров, ни справки. Восьмая же версия не скачивается почему-то.
Lasciate ogni speranza, voi ch'entrate.

alibek
Большой Человек
Большой Человек
 
Сообщения: 14205
Зарегистрирован: 19.04.2002 (Пт) 11:40
Откуда: Russia

Сообщение alibek » 11.02.2005 (Пт) 22:30

Вопрос частично снимается. Я неправильно соединение открывал, надо было не указывать Collating Sequence.
Теперь все работает, и выборка, и асинхронность, но появилась другая проблема.
OLEDB работает на порядок, а то и на два медленнее ODBC. С ODBC, даже при условии того, что я перебирал весь рекордсет и вручную фильтровал в цикле по CODE, импорт все равно происходит быстрее, чем через OLEDB.
Lasciate ogni speranza, voi ch'entrate.

Ennor
Конструктивный критик
Конструктивный критик
 
Сообщения: 2504
Зарегистрирован: 18.12.2001 (Вт) 3:58
Откуда: Калуга -> Москва

Сообщение Ennor » 11.02.2005 (Пт) 23:52

Знаешь, я уже неоднократно замечал, что ODBC работает быстрее, чем OLE DB, причем я-то работал исключительно с MSSQL, и думаю, не надо говорить, насколько вылизаны его драйвера :). И даже на нем - все равно разница есть.

Я бы сделал так - перенес все DBF в тот же MSSQL (хотя бы) и работал бы дальше уже только с ним. Думаю, сам понимаешь, насколько богаче там возможности серверного программирования. Ну а при выходе обновленного кладра - написал бы DTS-пакет, который запускается (возможно, даже вручную) и заново перетягивает новые данные от ГНИ на сиквел. Имхо, это вариант.

alibek
Большой Человек
Большой Человек
 
Сообщения: 14205
Зарегистрирован: 19.04.2002 (Пт) 11:40
Откуда: Russia

Сообщение alibek » 12.02.2005 (Сб) 11:21

Нет, MS SQL мы отвергнем :)
Все что мне нужно от КЛАДР - это синхронизировать адресные справочники с ГНИ. Причем будет достаточно делать это раз-два в год. Так что текущего варианта пока достаточно, просто скорости жалко :)
Я еще поиграюсь с созданием запросов (либо на сервере буду курсор оставлять, либо Fetch-ить в фоне).
Lasciate ogni speranza, voi ch'entrate.

Andrey Fedorov
Член-корреспондент академии VBStreets
Член-корреспондент академии VBStreets
 
Сообщения: 3287
Зарегистрирован: 21.05.2004 (Пт) 9:28
Откуда: Москва

Сообщение Andrey Fedorov » 14.02.2005 (Пн) 10:13

OLEDB должен работать достаточно быстро. Может что-то у тебя все-же не так? На чем затык (выборка или обновление)?

Если выложишь OLEDB-шные драйвера и заполненные таблички с кратким описанием того что хочешь, то могу покопаться в свободное время (пока оно есть)... Хотя на 100% не обещаю результата - просто самому интересно посмотреть...
Фиг Вам! - Сказал Чебурашка, обгладывая Крокодила Гену...

alibek
Большой Человек
Большой Человек
 
Сообщения: 14205
Зарегистрирован: 19.04.2002 (Пт) 11:40
Откуда: Russia

Сообщение alibek » 14.02.2005 (Пн) 10:41

Драйвера брал на сайте MS (vfpoledb9).
Таблички - обычный КЛАДР, который распространяется ГНИ (только DBF-версия, а не текстовый файл).
Общая маска поля CODE в КЛАДР имеет такой вид:
AADDDCCCIII[SSSS]
AA - две цифры области (остальные нули)
DDD - три цифры района (остальные нули)
CCC - три цифры города (остальные нули)
III - три цифры населенного пункту (поселки, деревни и пр.)
SSSS - четыре цифры улицы, только для списка улиц.

Нужно перегнать данные в свою базу, которая имеет таблички (NAME, TYPE это название и сокращенный тип (ул., г., обл. и т.п.)):

REF_ADR_COUNTRY (страны)
- COU_KEY
- NAME

REF_ADR_AREA (области)
- ARE_KEY
- COU_COU_KEY
- NAME
- TYPE

REF_ADR_DISTRICT (районы)
- DST_KEY
- COU_COU_KEY
- ARE_ARE_KEY
- NAME
- TYPE

REF_ADR_CITY (города и населенные пункты)
- CIT_KEY
- COU_COU_KEY
- ARE_ARE_KEY
- DST_DST_KEY
- NAME
- TYPE

REF_ADR_STREET (улицы)
- STR_KEY
- CIT_CIT_KEY
- NAME
- TYPE
Lasciate ogni speranza, voi ch'entrate.

Andrey Fedorov
Член-корреспондент академии VBStreets
Член-корреспондент академии VBStreets
 
Сообщения: 3287
Зарегистрирован: 21.05.2004 (Пт) 9:28
Откуда: Москва

Сообщение Andrey Fedorov » 14.02.2005 (Пн) 11:28

alibek писал(а):Драйвера брал на сайте MS (vfpoledb9).


Не - так неинтересно ;)

Надо DBF-таблички с данными, так и собственно базку содержащие их-же но которую нужно синхронизировать. Тогда еще что-то возможно сделать и нормально протестить.
-------------------------------------------
Но подобное делал - в общем, как добиться максимальной скорости синхронизации таблиц в двух базах:

Выдергиваем таблички из обоих баз в статические курсоры и устанавливаем у ключевых полей Optimize = True.

Далее просто сканируем образцовые таблички (начать лучше с мелких справочников) с поиском соответствующей (Find), если не найдена - добавляем. Найдена - сравниваем поля, если есть различия то изменяем и сохраняем.

Потом уже сканируем синхронизируемые таблички с поиском соответствия в образцовых и, если не найдено, то удаляем.

Как результат - миниум запросов собственно к таблицам и максимально возможная скорость.

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

У меня такое делается ежедневно - синхронизация с заводской базой (у них не VFP, а клиппер, файлы DBF). Самая большая синхронизируемая табличка 100000 записей. Но у меня даже посложней - я из одной ихней делаю несколько своих...
Фиг Вам! - Сказал Чебурашка, обгладывая Крокодила Гену...


Вернуться в Базы данных

Кто сейчас на конференции

Сейчас этот форум просматривают: AhrefsBot и гости: 1

    TopList  
cron