Общеизвестно, что курсор, полученный командой SELECT-SQL можно переоткрыть в другой области, если использовать в запросе NOFILTER.
Но мне нужно переоткрыть в другой области курсор, полученный с MS-SQL.
На команду USE (DBF(MyCursor)) AGAIN ALIAS NewCursor выдется сообщение , что DBF c неким страшным сгенерированным именем не найден. А опции NOFILTER в SQLEXE нет.

Попробуй так:

1. Для RV - Use RV in 0 Alias RV1 - произвести выборку заново

2. Для SqlExec - SqlExec(hnd,command,'RV1') - вообщем тоже, что и RV

На худой конец Copy to

Поправочка:


IN 0 добавлено!

To Tass - не помогает, дело в том, что курсор хранится в буфере, а самого файла физически нет.

Вспомнил из досовского прошлого FLUSH. Не помогло.

Тогда попробуй скопировать его в эту новую область:

Hi Сергей!

А зачем тебе это понадобилось? Описанный трюк с переоткрытием был полезен в VFP6 и более ранних, для того чтобы сделать результат SQL запроса (к локальным данным) редактируемым - с появлением опции READWRITE его использование потеряло смысл. Результат же запроса удалённых данных (что RV, что SQLEXEC) всегда порождает редактируемые курсоры, так что и "переоткрывать" их смысла как-то не видно...

Задача состоит в том, чтобы не делать лишних запросов. В отделе кадров вводятся адреса, после ввода региона, города или населенного пункта в составе города загружается список улиц. В 80% случаев регион -
Санкт-Петербург. Мы запоминаем последнюю комбинацию регион-город-нас.пункт и если текущая с ней не совпадает - посылаем запрос на сервер. Причем, я добиваюсь того, чтобы , если запрос ничего не вернул, не заменять курсор пустым. Поэтому первоначально я получаю резульнат в курсор с другим именем и, если он не пустой, пытаюсь открыть его в алиасе для последнего набора улиц.
Вариант, предложенный Анатолием, в принципе годится (без append from (dbf('sqlcursor')) ), но больно уж долго проходит копирование по записи.

Предварительно можно спросить у сервера есть ли записи удовлетворяющие вашему условию:
select count(*) as cnt from ... where ...
Потом если cnt>0 посылать полный запрос.

Тоже интересный вариант. Как всегда все упирается в скорость. Насколько быстрее этот запрос выполняется, чем запрос с полной выборкой? Ведь не нужно гнать данные по сети.
В общем , буду проверять.

Ну, а сделать просто SELEct из созданного курсора в другой курсор - вроде выход.

To PaulWist.
И как я сам не догадался. Похоже, это то, что нужно. Хотя непонятно, как это работает внутри фокса.
Если делать SELECT из нередактируемого курсора, то, скорее всего, даже не происходит никакого копирования в новую виртуальную таблицу, а вот как происходит SELECT из редактируемого ?

Ну, проведи эксперимент

Hi Сергей!

Понятно...

В общем-то вариантов много, и у всех есть свои слабые и сильные стороны...

У твоей схемы кэширования (которую можно "улучшить" проводя не "замену" результата, а его "накопление" в особом курсоре-кэше, а уже из него "выбирать" в рабочий курсор "для показа") есть один существенный недостаток - резкое падение актуальности данных - ну как и в любой другой кэширующей схеме - источник обновился, а мы "не в курсе". Для условно статичных данных это конечно не сильно мешает - можно обойтись банальной кнопкой "Обновить". Для динамической же части это не годится в принципе - т.е. чем быстрее мы избавимся от кэша - тем лучше (тем быстрее мы увидим "новые" данные).

Если идёт локальная "правка" данных этого кэша - задача немного усложняется - нужно/можно ли считать "неподтверждённые" (несохранённые) данные правильными? IMHO нет - их может не пропустить СУБД (триггера и прочие "ограничения").

Запросы типа COUNT(*) нужно проверять - по трафику они конечно очень эффективны, а вот как их "переваривает" твоя конкретная СУБД - большой вопрос. Я слышал диаметрально противоположные мнения насчёт таких запросов...

P.S. В Клиент-сервер не стоит сразу вынимать полный список (разве что заранее известно что там будет 100-200 записей - не больше). Т.е. возможно стоит ввод сделать через текстбокс, куда пользователь введёт начало/часть названия улицы - и лишь потом пройдёт запрос, уже сильно ограниченный этим условием... Я не в курсе сколько улиц в Питере, но думаю прилично - и всё равно пользователь из полного списка будет выбирать улицу посредством какого-нить IncrementalSearch или просто Find...

Попробую внести ясность по поводу запросов типа COUNT(*).

1. Поскольку автор явно указал, что сервер MS-SQL могу заверить, что MsSqlServer для такого запроса, как правило строит совсем другой (более быстрый) план выполнения, чем без count.
2. А поскольку на самом деле нужно знать лишь факт наличия записей по заданному условию. Еще быстрее будет запрос
select top 1 any_column from ... where ...
Без ORDER BY !.
или такой
if exist (select any_column from ... where ... )
select 'есть' as ret
else
select 'нет ' as ret

3. А еще лучше создать на сервере две хранимые процедуры с готовыми запросами. Одну для проверки, другую для выборки. Это исключит время компиляции.

и p.s. Для получения должного эффекта надо тщательно спроектировать индексы

Спасибо всем за обстоятельные ответы. Вариантов теперь такое множество, что мысли разбегаются.
Испробовал все предложенные варианты, и все работают вполне удовлетворительно.