Скачать: CL | DM;

Подскажите, а как пользоваться with lock в FB?   Найти похожие ветки 

← →
antoxa2005   (2006-06-28 15:24) [0]

Запускаю с одном приложении select * from mytable where id=2 with lock, во второй программе делаю тоже самое программа просто виснет. Как мне узнать, что запись заблокирована т.е. ее кто-то редактирует.

---

← →
Sergey13 ©   (2006-06-28 15:33) [1]

http://www.ibase.ru/devinfo/ibtrans.htm

---

← →
Desdechado ©   (2006-06-28 15:38) [2]

> программа просто виснет
первая или вторая?

А вообще в параметрах транзакции по умолчанию стоит WAIT, т.е
WAIT [Default] Specifies that a transaction wait for access if it encounters a lock conflict with another transaction
Что в переводе - будет ожидать, пока блокировка будет снята.

---

← →
Desdechado ©   (2006-06-28 15:39) [3]

Тебе, видимо, NO WAIT нужно.

---

← →
antoxa2005   (2006-06-28 18:58) [4]

А как это прописать. И где по умолчанию стоит WAIT сво-во param пустое.

---

← →
unknown ©   (2006-06-28 19:56) [5]

> antoxa2005   (28.06.06 18:58) [4]

Если мышкой 2 раза щелкнуть на компоненте TIBTransaction, то вылезет
редактор параметров, в нем ставим галочку "Read committed"
или ручками пишем в параметры
read_committed
rec_version
nowait

---

← →
antoxa2005   (2006-06-29 04:04) [6]

Открываю IBDataSet, вижу данные в DBGrid, начинаю править( запись с IDSPRKLIENT=2) -> IBDataSet переходит в состояние редактирования.

Открываю запрос IBQuery1 с SQL текстом:

SELECT *
FROM NEW_TABLE
WHERE IDSPRKLIENT=2
FOR UPDATE WITH LOCK

Ни чего не происходит, т.е. он не сообщает, что запись блокирвана.

Как же узнать, находится ли запись в процессе изменения?

---

← →
ЮЮ ©   (2006-06-29 07:35) [7]

> т.е. он не сообщает, что запись блокирвана.


А с чего она заблокирована? Вот данный запрос её заблокировал. А состояние редактирования в IBDataSet никак не отражает состояние записи на сервере.

З.Ы. какого вообще следить за тем, что кто-то изменяет запись, которую хочешь изменить другой пользователь? Чем эта ситуация опасней той, что 1ый пользователь секунду назад изменил запись, а 2-ой этого и не заметил?

---

← →
antoxa2005   (2006-06-29 07:44) [8]

Если один открыл на изменение, другой открыл изменил и сохранил, то "один" при сохранении получает ошибку ...lock....

---

← →
ЮЮ ©   (2006-06-29 08:09) [9]

А почему один в столь невыгодном положении, потому что 2-ой шустрее?

А как ситуация, о которой я спросил чуть выше:
1 открыл изменил сохранил. 2 все равно не увидит изменений и изменит так, как считает нужным. 1 при этои не увидит изменений сделанных 2, если, конечно,  IBDataSet не будет обновлен.

З.Ы. Не должно у двух пользователей системы возникать желания изменять одну и ту же запись, причем совершенно разными данными.  А если так поставлены дела в консерватории, то чего замарачиваться

---

← →
ЮЮ ©   (2006-06-29 08:38) [10]

Если один открыл на изменение, другой открыл изменил и сохранил, то "один" при сохранении получает ошибку ...lock....

Это так работает или так хочется?

Если хочится, тогда уж логичнее было бы при переводе IBDataSet в dsEdit выполнять тот самый  IBQuery1, тем самым проверяя "занята" запись или нет и  позволять редактировать только если "свободна".

А если так работает, то, очевидно надо что-то ещё отправлять серверу, чтобы снять это самое FOR UPDATE WITH LOCK

---

← →
Jeer ©   (2006-06-29 14:14) [11]

Повторю из соседней ветки:

http://www.ibase.ru/devinfo/pslock.htm
http://www.ibase.ru/devinfo/plocks.htm

---

← →
Виталий Панасенко   (2006-06-29 14:34) [12]

to antoxa2005 - скажи мне, какая разница в такой ситуации: пользователь 1 менят значение в записи. а после этого пользователь 2 меняет эту же запись через 0,0001 секунды или 1 мунуту ? или 1000000 лет ? что от этого меняется ?"кто последний, тот и папа"... а описання тобой ситуация возможна при наличии конкретного бардака в организации делопроизводства, когда на стол к разным операторам попадают документы по коррекции существующих, с разными условиями(при чем одного и того же)...

---

← →
antoxa2005   (2006-06-29 15:00) [13]

> to antoxa2005 - скажи мне, какая разница в такой ситуации:
>  пользователь 1 менят значение в записи. а после этого пользователь
> 2 меняет эту же запись через 0,0001 секунды или 1 мунуту
> ? или 1000000 лет ? что от этого меняется ?"кто последний,
>  тот и папа"... а описання тобой ситуация возможна при наличии
> конкретного бардака в организации делопроизводства, когда
> на стол к разным операторам попадают документы по коррекции
> существующих, с разными условиями(при чем одного и того
> же)...

Это вразумляет!

---

Страницы: 1 вся ветка

Скачать: CL | DM;



Память: 0.48 MB
Время: 0.025 c