|
su.dbms.sql
- SU.DBMS.SQL ------------------------------------------------------------------
From : Tolik Tentser 2:5020/400 11 Apr 2001 18:44:45
To : All
Subject : Re: Дремина хитрость 2
--------------------------------------------------------------------------------
Hi, Tolik Gusin!
В чреве акулы, пойманной Tue, 10 Apr 2001 15:01:28 +0000 (UTC),
дети капитана Гранта нашли письмо на тему 'Re: Дремина хитрость 2':
>А в MSSQL 6.5 и 7.0 было @@SCOPE_IDENTITY ?
Hет
>> Что, пользователь в форме будет вносить в Detail значение Identity из
>> MASTER ?
>Hет конечно пользователь это значение не вводит, оно вводиться
>автоматически.
>Hо ведь все равно его сначало надо получить от таблицы MASTER, а просто
>так это не получаеться сделать.
Почему ?
При вставке - элементарно, а на клиенте при редактировании - оно и не
нужно совсем
>В общем то ни кто, но это легко сделать если у тебя One Master-One
>Detail и применительно к Delphi ты можешь вводить и хранить значение
>Detail в обычных контролах типа TEdit.
Hу давай не будем возводить ограничения клиентского инструментария
работы с БД Delphi (не слишком, кстати, удачного) в ранг недостатков
серверов.
>> Какой сервер ?
>SQL AnyWhere 5.5.05
>
>> А что он на блокировке не ждет ?
>В SAW есть специальная опция которая отвечат за реакцию на блокировку
>записи:
>1) Blocking=On. В этом случае, если строка заблокирована, то сервер ждет
>некторое время пока она освободиться (это время указываться в другом
>параметре типа TimeOut) и только после этого выкидывает ошибку и
>сообщает что строка заблокирована.
>2)Blocking=Off. В этом случае, если строка заблокирована, то сервер
>сразу выкидывает ошибку и сообщает что строка заблокирована.
>
>Я предпочитаю вариант 2.
Лучше-таки немного подождать (1-5 секунд). А так ты вздуваешь обмен по
сети на абсолютно ровном месте.
>> К тому же - тут у тебя хорошее место для deadlock`ов
>Почему ?
Сначала SELECT (видимо в RR транзакции ?), потом UPDATE
Если после SELECT вклинится другая транзакция с теми же действиями -
получишь тот самый DEADLOCK. Учитывая, что это место вызывается
довольно часто ...
>Кстати если это тебе не сложно, то расскажи подробно как ты поступаешь в
>таких ситуациях ?
В которых конкретно ?
>Как ты работаешь со связками One Master-Many Detail в описанной мною
>ситуации ?
При редактировании объккта (счета, например) он грузится на сервер
приложений, который выдает клиенту для редактирования клиенту свойства
объекта (в частности - свойство может иметь тип "датасет", содержащий
Detail записи). Клиент запрашивает нужные свойства, а потом отправляет
измененные их значения на сервер приложений, который сравнивает
состояние объекта до и после релактирования и генерирует SQL для
сохранения изменений в БД.
Если это новый объект, то вначале идет вставка в таблицу объектов и
получение IDENTITY, если не новый - его ID уже известен. Дальше во
всех INSERT`ах в Detail - используется это значение.
Клиент вообще знать не знает, что есть какой-то SQL, он устанавливает
поля объекта
Bye ...
Тенцер А.Л.
tolik@katren.nsk.ru
ICQ 15925834
--- ifmail v.2.15dev5
* Origin: AO Katren (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
