DmitrO писал(а) 19. Декабря 2006 :: 05:53:

Если это возможно, то это, по-моему, лучший вариант!

DmitrO писал(а) 19. Декабря 2006 :: 07:25:

Ага, про разрегистрацию очень интересный вариант.

По поводу задачи отображения в ТП данных dbf формата ИБ.
Использование VFP провайдера действительно чревато проблемами блокирования. Грязное чтение реализовать весьма сложно. Если просто отменить блокирование, тогда можно запросто получить при чтении неформатные данные в файле, т.к. сама 1С в это время их пишет.
Имхо лучше направить усилия в направлении написания специального поставщика данных, не SQL. В котором таблицы-источники данных, их связи и поля, будут добавляться методами объекта поставщика данных, принимающими объекты метаданных или имена объектов метаданных. Т.о. реализация такого поставщика может быть выполнена через родные функции доступа к dbf ИБ, а следовательно и через родные дескрипторы файлов. Т.е. будет работать и в монопольном режиме.

DmitrO писал(а) 19. Декабря 2006 :: 10:11:

ИМХО, ЗАПРОСТО, получить не получится ИМХО, наоборот, крайне маловероятно. Например, если запрос использует индексы, то незавершенная операция записи в DBF-файл просто не затронется индексами и никак не сможет на что-либо повлиять. В этом случае проблема может возникнуть при незавершенной записи в индексы, но тут уже все зависит от того, как меняются индексы. Если просто в конец дописываются данные, а потом модифицируются некоторые записи, то вряд ли здесь будут проблемы. Ну и, в конце концов, 1С же работает (читает таблицы в процессе модификации)

DmitrO писал(а) 19. Декабря 2006 :: 10:11:

ИМХО, сложноватая задача для ДБФ, не стоит ДБФ таких усилий И действительно, как намекает spock, это сильно походит на реализацию OLE DB самопальными методами. Наверняка получится криво и не удобно по сравнению с OLE DB. Либо понадобится вложить столько работы, что проще будет базу перевести на SQL.

Хм, немного туплю. Речь ведь идет только о провайдере для ТП А я тут на прямых запросах заклинился Да, возможно, для поставщика ТП лучше будет XBase-подобные методы использовать

Кстати, может вообще не заморачиваться на создание поставщика для OLE DB? А сделать вместо него некий "УниверсальныйПоставщикТП". Он будет использовать некоторый класс со специальными методами по выборке данных. Тогда используя универсальный поставщик можно хоть поставщика для OLE DB сделать, хоть для чего угодно другого

Потестировал еще немного OLE DB. Обнаружил грустную вещь: крайне криво работает "SELECT TOP N". (Может, конечно, я запросы неправильно пишу). Возникает впечатление, что сначала делается полная выборка как при отсутствии "TOP N", а затем из этой выборки вытаскиваются первые N записей. Обнаружил это из-за того, что в некоторых случаях поиск по наименованию происходит крайне быстро, а в некоторых наоборот крайне медленно. Причем, от расположения записи в файле зависимости нет, т.е. индексы используются.

Итак, тестовый запрос:

		|SELECT TOP 1
		|	Товары.Descr AS Наименование
		|FROM
		|	$Справочник.Товары AS Товары
		|ORDER BY Товары.ID
 

Этот запрос должен выполнять мгновенно, но тем не менее сильно тормозит на большом справочнике.

Поэтому получается, что текущий способ организации поставщика ODBC не подходит для создания по аналогии поставщика OLE DB. Думаю, что поставщик ODBC для VFP также не подходит для использования в ТП (но это надо еще проверить).

Думаю, что для поставщика OLE DB нужно использовать для доступа к данным 1С методы XBase (SEEK, в частности). Я считаю, что все равно надо использовать OLE DB, т.к. мало простой навигации по таблице и нужно еще выполнять некоторые запросы к БД. Например, при навигации по справочнику товаров можно выводить остатки. Так вот поставщик данных мог бы вытащить из БД некоторый набор элементов справочника, а потом для них всех скопом выполнить один запрос к таблице остатков. Аналогично для таблицы журнала документов - можно скопом вытащить наименования все контрагентов для отображаемых документов. А для подобных вещей лучше использовать возможности OLE DB. Самостоятельная реализация наверняка будет хромать.

Дело в том, что если все нужные поля выбирать методами XBase, то будет наоборот сложно в том случае, когда мы выбираем не только поля одной таблицы, но должны еще джойнить другие.

А проще будет, когда используем такой алгоритм:
1) В поставщике устанавливается базовая таблица и ключевое поле.

2) Для навигации по таблице используем методы XBase. При этом при подгрузке новой порции данных выбирается список ключей.

3)Далее этот список ключей используется для выполнения SQL-запроса методом OLE DB. Этот SQL-запрос устанавливается в поставщике при инициализации. Запрос выполняется и дальше с результатами происходит все то же самое, что сейчас происходит в ODBC-провайдере.

Получается, что отличия от SQL-провайдера минимальны - только добавлена установка базовой таблицы и XBase-навигация и выборка ключевых полей. Остальное точно такое же.