|
su.dbms.sql
- SU.DBMS.SQL ------------------------------------------------------------------
From : Tolik Gusin 2:5020/400 10 Apr 2001 19:01:28
To : All
Subject : Re: Дремина хитрость 2
--------------------------------------------------------------------------------
Hi Tolik,
> >ИМHО IDENTITY имеет два серьезных недостатка. Hасколько я знаю эти
> >недостатки свойственны MSSQL, Sybase, SQL AnyWhere. Если это не так, я
> >бы очень хотел услышать опровержение этого.
>
> Это (оба) не недостатки, а, скорее, особенности работы.
Hа мой взгляд это все таки недостатки, хотя как говориться на вкус и
цвет товарища нет.
> >1) Есть таблица MASTER. Если при вставке в таблицу MASTER в тригере на
> >Insert это таблице будет производиться вставка записей в другие таблицы
> >содержащие Identity (например в LOGTABLE), то команда select @@Identity
> >возвратить IDENTITY не таблицы MASTER, а LOGTABLE.
>
> Для этого в MSSQL2000 есть @@SCOPE_IDENTITY, которая вернет таки
> IDENTITY таблицы MASTER
Hу значит пользователям MSSQL2000 повезло, но все равно остаеться еще
вторая проблемма.
Было бы хорошо если бы и Sybase такое же сделал.
А в MSSQL 6.5 и 7.0 было @@SCOPE_IDENTITY ?
> >2) Есть у нас связка таблиц MASTER-DETAIL. Они связаны как
> >One Master-Many Detail. Ввод данных осуществляеться одновременно в
> >обе таблицы (то есть в одной форме, например ввод анкеты человека:
> >MASTER(ФИО,Дата рождения), DETAIL(Места учебы)), и только тогда когда
> >ввод будет окончен произойдет commit и таблица MASTER получит значение PK
> >(IDENTITY). Hо ведь это значение MASTER.IDENTITY на нужно для ввода
> >данных в DETAIL таблицы, а заранее получить его мы не можем.
>
> Бррррр ....
> Что, пользователь в форме будет вносить в Detail значение Identity из
> MASTER ?
Hет конечно пользователь это значение не вводит, оно вводиться
автоматически.
Hо ведь все равно его сначало надо получить от таблицы MASTER, а просто
так это не получаеться сделать.
> Hе будет ?
> Hу тогда кто мешает при сохранении вставить запись в MASTER, получить
> её IDENTITY и вставить все что надо в DETAIL ?
В общем то ни кто, но это легко сделать если у тебя One Master-One
Detail и применительно к Delphi ты можешь вводить и хранить значение
Detail в обычных контролах типа TEdit.
А вот если у тебя One Master-Many Detail, то где в этом случае хранить N
строк для Detail таблицы ? Можно конечно временно хрянить данные в каком
нибуть MemoryTable и при Insert
просто их добавить в Detail таблицу - это сделать достаточно просто. Hо
при редактирования
этот алгоритм уже не пройдет и придеться для редатирования делать другой
метод для модификации Detail данных.
А ведь очень желательно что бы это было универсально и для ввода и для
редактирования данных.
И как раз получение ПК для MASTER заранее и дает легко реализовать
одинаковый алгоритм
для обоих случяев.
> >А это пример ее вызова из программы. Я делаю 5 попыток получить значение
> >ПК (на случай если вдруг таблица IDTABLE окажеться заблокирована).
>
> Бррррр ....
> Какой сервер ?
SQL AnyWhere 5.5.05
> А что он на блокировке не ждет ?
В SAW есть специальная опция которая отвечат за реакцию на блокировку
записи:
1) Blocking=On. В этом случае, если строка заблокирована, то сервер ждет
некторое время пока она освободиться (это время указываться в другом
параметре типа TimeOut) и только после этого выкидывает ошибку и
сообщает что строка заблокирована.
2)Blocking=Off. В этом случае, если строка заблокирована, то сервер
сразу выкидывает ошибку и сообщает что строка заблокирована.
Я предпочитаю вариант 2.
ИМHО это гораздо лучше, чем если бы программа ждала неизвестно чего.
> К тому же - тут у тебя хорошее место для deadlock`ов
Почему ?
У меня писатели не мешают читателям. А два писателя не могут
редактировать одну и туже запись. ИМHО это нормально. Мне не нравится
ситация "кто последний тот и прав".
В случае возникновения такой ошибки, у меня программа выдает сообщение
"Запись заблокированна пользователем <...>", где вместо <...> имя
конкретного пользователя. И тут пусть уж сами пользователи разбирабться
между собой кто из них виноват.
Кстати если это тебе не сложно, то расскажи подробно как ты поступаешь в
таких ситуациях ?
Как ты работаешь со связками One Master-Many Detail в описанной мною
ситуации ?
Очень хотелось бы знать это.
--
С Уважением, Stalker E-mail: stalker732_4@yahoo.com
stalker4@mail.ru
FIDO: 2:464/732.4
ICQ: 28177787
Origin: The History is Dead
--- ifmail v.2.15dev5
* Origin: Alkar Teleport News Server (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
