Чтобы не грузить систему отправляю клиенту (1С , не FoxPro) данные порциями (например по 100 записей). Требуется 100 записей идуших(по возрастанию индекса) за выбранным значением индекса.

Напрашивается Select TOP 100, но к сожалению FoxPro в этом случае сначала полностью
считывает всю таблицу удовлетворяющую условию WHERE, потом упорядочивает данные,
и только потом выдает 100 первых записей - т.е. действует крайне неоптимально.

Если же выбирать между двумя фиксированными значениями индекса FoxPro получает данные
очень быстро. Т.е. если я знаю значение ключа индекса в N - мне нужно получить значение индекса N+100 записи.

P.S>Индексы CDX, сами выражения сложные, например sp1006+DTOS(date)+time+iddoc

Sergey Sizov.Саш, да обычную постраничную выборку товарисч хочет, но свое желание, как обычно :), закамуфлировал так, что не сразу и разберешься. Особенно, опять же :), как обычно :), когда рассказывает не задачу, а выбранный способ решения.
Что мешает сделать один раз выборку select ... where into cursor tmpcursor, а затем из этого курсора select ... from tmpcursor where recno() between var1 and var2, где var1 и var2 - номера записей от и до?

Так как нужно страничную выборку делать в режиме реального времени.
Работаю через OLEDB и созданный таким образом курсор не обновляется.

Вопрос в заголовке -: есть номер записи, например 1000.
Как получить значение ключа индекса в записи номер 1000.

Станислав С...кий kiruhaЧтобы не грузить систему отправляю клиенту (1С , не FoxPro) данные порциями (например по 100 записей). Требуется 100 записей идуших(по возрастанию индекса) за выбранным значением индекса.

Напрашивается Select TOP 100, но к сожалению FoxPro в этом случае сначала полностью
считывает всю таблицу удовлетворяющую условию WHERE, потом упорядочивает данные,
и только потом выдает 100 первых записей - т.е. действует крайне неоптимально.

Если же выбирать между двумя фиксированными значениями индекса FoxPro получает данные
очень быстро. Т.е. если я знаю значение ключа индекса в N - мне нужно получить значение индекса N+100 записи.

P.S>Индексы CDX, сами выражения сложные, например sp1006+DTOS(date)+time+iddoc
В этом случае надо делать перемещение по индексу (остальные "шероховатости" Фокс возьмет на себя):


Я это сделал (с небольшим поправками на работу с файлами ДБФ)
Проблема в вычислении
new_key=<выражение для фильтра>
Так как индексов и таблиц много - <выражение для фильтра> для всех индексов разное.
Только ExecScript ?

StrIndeks=SYS(14,1,xAlias)
NewKey=''
EXECSCRIPT('NewKey='+StrIndeks)
?NewKey

Только так?
Нет методов вычислить значение ключа ?

Sergey Sizov.Кстати, execscript тут совсем не нужен. Достаточно


Большое спасибо ! :)
execscript не нравится, так как пишут что каждый раз идет компиляция скрипта.

P.S. Странно, что оптимизцией Select TOP никто не озадачивался.

Sergey Sizov. kiruhaP.S. Странно, что оптимизцией Select TOP никто не озадачивался.
И из чего вытекает такое утверждение? Он плохо выдает первые записи?

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

Sergey Sizov. kiruhaЕсли нужно получить 100 последовательных записей(по индексу) из середины
таблицы, то по сравнению с выборкой между 2-мя индексными значениями
у меня выполнение в несколько сот раз дольше.
Каким боком ТОР, то есть ПЕРВЫЕ записи, относится к середине? На каком основании сделано предположение, что ТОР выдернет что-то из середины?

Например таблица товары.
В Grid нужно обновить текущую страницу.
Верхняя запись ID=myID
По ID построен индекс.
Или пользователь просматривает доументы за прошлый год.
Нужно 100 после 01.01.2007

Sergey Sizov.И что нам этот код должен продемонстрировать? Тем более что из 10 записей 100 не выдернешь. Пояснения будут?

ТОР в любом случае выдернет только ПЕРВЫЕ записи, в том порядке, который ЯВНО указан словом ORDER. Select использует индексы не для упорядовчивания. Порядок выдачи записей определяет только ORDER. А уж после чего эти первые записи определяйте в WHERE.

10 только для примера. Можно написать 100 - сути это не меняет.
И в запросе не нужны "первые 100 записей таблицы вообще", а нужны первые 100 записей
из записей больших чем myId.

Кстати и без условий WHERE запрос будет обрабатываться достаточно долго.
Вы может проверить это на любой своей таблице - именно это я и хочу продемонстрировать.

Сравнить с аналогом

Sergey Sizov.
Ну и где запрос на выбор записей с id больших чем myId? Это во-первых. Во-вторых, начинать надо с самых больших? С самых меньших? С каких?

Запрос был приведен :
Работает 6 месяцев без проблем (по верности результата, а не скорости выполнения).
ORDER BY отрабатывается после WHERE, а не до.

Sergey Sizov.
У меня появилось предположение, что Вы считаете, что TOP и индексы как-то связаны. Если так, то это глубокое заблуждение.
Да, я ожидал что драйвер сообразит использовать индекс в этом случае.
Увы. Поэтому и завел ветку - теперь после нахождения myId1 и myId2 в процедуре -
он отрабатывается достаточно быстро.