Hi All!

Да уж, нагородили столько бреда на пустом месте, что аж жутко становится...

Любителям параметризованных View с последующим Requery()+GO BOTTOM
посвящается.

На сервере примитивная таблица с IDENTITY полем. На фоксе представление.

CREATE SQL VIEW View1 CONNECTION ... AS ;
SELECT ID, Name FROM SomeTable WHERE Name LIKE ?m.MyStencil
* Настроим также обновление поля Name? можно и Id хотя смысла в том нету.

Можно сделать?

MyStencil = "ИВАН%"
USE DB!View1

Можно сделать? Какие данные будут в курсоре?

INSERT INTO View1 (Name) VALUES ("ПЕТРОВ")

Можно? Что будет в курсоре?

? TABLEUPDATE("View1")

Можно? Что после этого будет на сервере?

? REQUERY("View1")
GO BOTTOM

Теперь смотрите на результат - если вы увидете там вашу новую запись, и
соответственно новый ID - и при этом предварительно не покушаете
галлюциногенных грибочков, то вы видимо знатный шаман :)

Чуть меняем запрос в представлении:

SELECT ID, Name FROM SomeTable ORDER BY Name

И что, вы по прежнему будете настаивать на том что REQUERY()+GO BOTTOM даст
значние "нового" ID господина "Петрова", а не того ID который был скажем у
господина "Якина" находящегося последним по алфавиту в списке?

Даже ещё проще! Возьмите вашу СУБД и проведите с ней простую работу -
вставляйте последовательно записи, РУКАМИ наращивая значение некоторого поля
(не IDENTITY конечно) - вставив несколько тысяч записей удалите из них
половину или лучше процентов 90 (желательно в случайном порядке - но можно и
большими блоками) - потом снова вставляйте и снова удаляйте - в конце концов
в результате выборки БЕЗ опции ORDER BY вы получите не "последовательно
возрастающие коды", а полную мешанину - это просто иллюстрация того простого
принципа, что в подавляющем большинстве СУБД НЕ СУЩЕСТВУЕТ понятия
"физической последовательности записей"! И уже одно это отправляет ваш
REQUERY()+GO BOTTOM на помойку.

Ну про то что "я никогда не видел как в базу параллельно вставляется
несколько записей в течении одной секунды" - уже сказано - это порочная
логика - то что девелопер не в состоянии достаточно синхронно нажать 2
кнопки на 2-х клавиатурах не означает что это невозможно в принципе.

И вообще не стоит себя вести как капризный ребёнок - если говорят что так
делать нельзя, и тем более если дают ссылки на то как НУЖНО делать - не "от
себя", а от производителя соответствующего сервера! То наверное стоит не
спорить, а читать и думать, думать и читать!

Что касается CAD - это по сути RV и есть - они работают во многом
идентично - но в отличие от RV он позволяет гораздо больше вмешиваться в
процесс запроса/сохранения - в частности в VFP9 через группу свойств
*RefreshCmd и/или методы CAD позволяет практически автоматически получать
присваиваемые сервером значения - т.е. делать тот самый мелкий Refresh (а не
полный REQUERY который к тому-же может и не те записи вернуть и не в том
порядке в каком они были).
Кстати пример с CAD был не очень удачный - он основан на идее использования
ключа-кандидата, а такового может и не быть в наличии! А вот @@IDENTITY есть
всегда - ну или SCOPE_IDENTITY() - но в одном батче с самим INSERT (а проще
видимо в ХП).

Posted via ActualForum NNTP Server 1.3