kms писал(а) 27. Октября 2007 :: 13:50:

SKIP как раз работает (условно) за константное время. Со сложностью SEEK работает GOTO при установленном индексе. Или, вероятно, SET ORDER, если мы спозиционированы на записи.

Табличная блокировка автоматом накладывается Фоксом при (всех?) операциях. Поэтому SEEK должен быть атомарным. Но в патченном vfpoledb.dll блокировки отсутствуют и тут да, может выйти облом. Правда, не понятно, насколько лучше здесь обстоят дела у самой 1С - не удивлюсь, что у нее там то же самое.

Для проверки можно, наверное, параллельно запустить два процесса: один будет постоянно сикать (при помощи GOTO или напрямую) и брать некоторое (неизменямое) поле. А второй процесс может постоянно менять поле, входящее в индексное выражение. Соответственно, или что-то вылетит, или Фокс получит левое значение в первом процессе. Как-то так...

Я там чуть поправил - в принципе, достаточно блокировки записи.

Uzhast
ОК, пишу свою первую программу "хелловорлд" на фоксе.
Типа для ТП с разделением индексов.

1. SET ORDER TO IDD
2. GOTO НЕКИЙ_ID (как это правильно написать?)
3. LOCK текущая_запись
4. SET ORDER TO PDESCR // после этого мы готовы двигаться дальше по PDESCR с текущей записи, или нет?
5. SKIP 1
6. UNLOCK та_самая_запись

Подкорректируй, плз, как это должно правильно выглядеть, а я сложность прикину.
Ну смысл тот же - позиционируемся по одному индексу и дальше пляшем по другому.

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

Я Фокс знаю плохо (работал с ним очень давно). Но раз пришлось использовать prg, кое-что пришлось освоить Но попробую скорректировать. Если сразу не заработает - извини
1. SET ORDER TO TAG ИмяТега OF ИмяФайлаМожноБезРасширенияCDX
2. GOTO НЕКИЙ_ID (как это правильно написать)
Так. GOTO нужен физ.номер записи, а не IDD. Поэтому либо надо сначала узнать этот номер (при помощи SEEK), либо сразу сделать SEEK:
SEEK ЗначениеИД
После этого мы будем стоят на записи с нужным ИД. Или не будем.

3. LOCK - функция, принимающая список номеров записей через запятую в виде строки: LOCK('1,2,3,4', НомерРабочейОбластиИзКомандыUSEИлиПсевдонимТаблицыИзUSE). Номер текущей записи можно получить через функцию RECNO ()

4. SET ORDER TO PDESCR // после этого мы готовы двигаться дальше по PDESCR с текущей записи, или нет?
Не уверен, но, скорее всего (с большой долей вероятности), готовы. Если не получится, то всегда можно сделать GOTO на номер записи, полученный через RECNO () после SEEK.

5. SKIP 1

6. UNLOCK та_самая_запись
Синтаксис
Цитата:

Т.е. можно для простоты использовать UNLOCK ALL

Как я понимаю, еще опущены детали типа USE

kms писал(а) 27. Октября 2007 :: 14:38:

Дайте угадаю.
Что-то типа SET NEAR нужно?

Uzhast писал(а) 27. Октября 2007 :: 14:44:

Для upper_bound я бы попробовал поставить скорее в ON.
В OFF будет пролетать со свистом до самого конца (или начала).

Цитата:

T.e. схематично на ломаном русском upper_bound, видимо, можно записать как-то так:

SET NEAR ON
SEEK(IDD)
IF (FOUND)
  SKIP(1)
ENDIF

Здесь, правда, вижу тонкий момент в понятии 'closest index key', надеюсь мои представления не расходятся с представлениями авторов документации.

Итак, кратко резюмируем итоги дискуссии.
Напомню, с чего она начиналась:
Цитата:

Вопрос возник всвязи с организацией провайдера ТП для баз 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, и считать, что оно входит в конец любого индекса, а также само-по себе образует еще один индекс (обход в порядке номеров записей)

Тест dll от 26 вечер

Типовая торговля демо

Select * from Номенклатура
where Номенклатура.МинОстаток=2.000 

0 строк - в реальности одна -
любимые 'Женские ботфорты коричневые                       '

Select * from Номенклатура
where МинОстаток>2.000 

121 строка  - условию не соответствует

Select *
from
(Select
Descr
, МинОстаток

from Номенклатура ) as СпрНом

where СпрНом.МинОстаток=2.000 

также 0 строк, хотя по идее оптимизатор должен не работать?

orefkov писал(а) 28. Октября 2007 :: 17:38:


Брал типовую демо 9.2
Без отбора - ошибка, с отбором - нет