Итак, кратко резюмируем итоги дискуссии.
Напомню, с чего она начиналась:
Цитата:Вопрос знатокам индексов dbf файлов.
Сравниваю индексы в dd и в dds.
Справочники:
В sql есть индекс:
PARENTID,ISFOLDER,DESCR,ROW_ID - можно использовать как уникальный ключ для поставщика данных ТП.
В дбф:
PARENTID,ISFOLDER,DESCR(UPPER) - получается, нельзя использовать как уникальный ключ записи?
Или таки в дбф-индексы всегда неявно входит номер записи?
Вопрос возник всвязи с организацией провайдера ТП для баз SQLite, а в частности, использованию в нем виртуальных таблиц, отображающих родные таблицы 1С в дбф-версии.
Основная задача провайдера ТП - опираясь на данные о текущей строке ТП, выдать N следующих/предыдущих записей, которая суть преобразуется в следующую:
спозиционироваться в индексе на узле, следующим/предыдущем за узлом, представляющем текущую запись.
В системах на базе SQL, и в SQLite в частности, не оперируют таким понятием, как физический номер записи, и соответственно, возникает требование об уникальности индекса упорядочивания.
И как выяснилось в ходе дискуссии, таки да, в индексы для ДБФ файлов всегда неявно входит физический номер записи, что позволяет, используя его как дополнительный ключ, спозиционироваться в индексе.
При этом, поведение SQL и DBF провайдеров различаются - SQL будет всегда выдавать записи от СТАРОГО положения записи, а DBF - от текущего, которое могло изменится с прошлой выборки данных.
И чтобы иметь возможность совместить DBF-подход с движком SQLite в плане организации провайдера, необходимо расширить ключ, представляющий индекс дбф-файла, дополнив его номером физической записи, напрмер, создав виртальное поле таблицы, возвращающей индексный ключ + номер записи. Например,
order by Номенклатура.PARENTID_ISFOLDER_DESCR_ROW
где PARENTID_ISFOLDER_DESCR_ROW будет возвращать например
' 1 2Всякая всячина AC12'
А в реализации выборки из дбф-таблиц учитывать этот переданный номер записи.
Либо перейдя в индексе по ключу и ручками досканировать несколько записей, сверяя номера строк
(тогда поведение будет как в ODBC-провайдере, новые записи будут выдаваться от старого положения записи),
либо попробовать фокспро трюк - SET ORDER GOTO запись, если убедимся, что движок 1С поддерживает эту фичу
(тогда поведение будет как в 1С-курсорах, новые записи будут выдаваться от нового положения записи).
Именно расширение ключа номером строки я и имел ввиду, задавая первоначальный вопрос, и что мне также любезно предложил Uzhast в одном из своих постов.
Всем спасибо за увлекательное обсуждения. Для себя вопрос считаю закрытым.
Да, кстати, щас еще подумал. Можно сделать одно виртульное поле: например, RecNum, и считать, что оно входит в конец любого индекса, а также само-по себе образует еще один индекс (обход в порядке номеров записей)