Читаем стартовый топик.
Хочу обратить внимание, что сравнивать скорость с OLE DB FoxPro без указания полей выборки (select * )
теперь нельзя, так как 1sqlite к таблицам 1С добавляет виртуальные поля, представляющие индексы, и при
select * from приходится еще вытаскивать и доп.поля.

Или вместо ID или IDDoc тупо храним физический номер записи. Тогда все работает еще быстрее, чем с ID или IDDoc, потому что избегаем одного INDEX SEEK.

orefkov писал(а) 25. Октября 2007 :: 10:31:

Если у тебя возможность использования ТОЛЬКО SQL-запроса, то не получится. Но ты же имеешь прямой доступ к таблице 1С. Значит, у тебя есть возможность доступа к физическому номеру записи. Так что все выглядит просто:
1) Выбираем N строк с учетом упорядочивания. Для каждой строки запоминаем физический номер.
2) Когда ТП просит M строк с нужной строки, упорядочиваем записи, используя упорядочивающее выражение.
3) Переходим по физическому номеру записи к нужной.
4) Переходим к следующей/предыдущей записи в зависимости от того, в каком направлении двигаемся.
5) Выбираем M строк в нужном направлении.

Вообще, ИМХО, страсть использовать SQL-запросы для построения курсоров - пагубная.  Для курсоров лучше использовать XBase-подобные средства. А SQL-запросы в подобных задачах наоборот, вместо наглядности и простоты выборки данных, дают усложения и лишние тормоза на ровном месте.

kms писал(а) 25. Октября 2007 :: 11:09:

Не придется. А вот идеологию провайдера - точно. У меня все работает именно по такому принципу, что я описал. ТП менялось только в одном месте - в получении CDataProvider * из объекта CBLContext *

kms писал(а) 25. Октября 2007 :: 11:30:

Не надо упираться в организацию ODBC-провайдера. Она не является единственно верной и вообще этот провайдер лучше переделать под серверные курсоры (ИМХО).

Никакое ограничение на уникальность ключа порядка не снимается. Провайдер может определить некоторое поле, как поле, идентифицирующее строку выборки. И он определяет его. Только это поле уже может не иметь отношения с способу выборки строк. Вот и все.

Почему падает на неуникальных ключах не знаю, не видел ТП я глубоко не копал. И считаю, что это правильно - должно быть хорошое описание взаимодействия, чтобы не было необходимости глубоко копать код. У меня на глючном провайдере бывало, что функция вообще всегда FALSE возвращает и ничего А на неглючном провайдере у меня обычно все строки уникальны: в статическом используется порядковый номер записи в выборке, а в динамическом - физический номер записи.

Ну и вообще, если взять провайдер для ODBC, то в нем есть два метода: УстКлючПорядка и УстИДПоле. Так что и там ключевое поле не имеет отношения к выражению упорядочивания

kms писал(а) 25. Октября 2007 :: 12:09:

В работающей базе строку удалить нельзя. Это при удалении помеченных объектов может случиться Во всяком случае это утверждение действительно для справочников и документов. А вот для таблиц, скажем, итогов регистра такое может произойти. Но их в ТП не отображают обычно.

kms писал(а) 25. Октября 2007 :: 12:09:

А считаешь, что от запросов кряхтеть меньше должен? А если приделать в СКЛ нормальную прокрутку (с ползунком), то от чего, думаешь, больше будет кряхтеть? От нормального перемещения по таблице при помощи курсора или тормозного фетч-цикла при помощи запросов?

kms писал(а) 25. Октября 2007 :: 12:09:

Не знаю ИМХО, название выглядит некрасиво