ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Sybase ASA, ASE, IQ [игнор отключен] [закрыт для гостей] / блокировка selectом
22 сообщений из 22, страница 1 из 1
блокировка selectом
    #32787730
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ggg_old
Участник
Возможно вопрос тупой, но под вечер что-то торможу.
Есть два запущенных isql ASA9
В одном делаю select * from my_table (таблица с одним тестовым значением)
В другом запускаю truncate table my_table
Транкэйт висит и ждет, пока я в первом окне не сделаю rollback или любую другую операцию, которая не снимет шаред блокировку с таблицы.
Такое поведение мне не очень нравится. Хочется, что-бы select не лочил данные, если я явно не открываю транзакцию. Опция ISQL commit after each command помогает, но как-то не нравится, т.к. при ручной работе в ISQL операции типа COMMIT или Rollback хочется давать самому.
...
Рейтинг: 0 / 0
17.11.2004, 18:53
| Ответить | Цитировать | Написать  
блокировка selectом
    #32787793
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
При открытии курсора для возврата данных клиенту SELECT вешает на таблицу SHARE-блокировку, запрещающую ее изменение (не путать с ROW-блокировками). Пока клиент не закроет курсор или не выполнит COMMIT, СУБД не имеет права допускать изменения структуры данной таблицы. В отличие от DELETE оператор TRUNCATE TABLE относиться к разряду изменения таблицы, так как ему необходимо ее блокировать, чтобы выполнить быструю очистку данных, индексов и т.д. Соотвествующе естественно такая команда и будет висеть, пока остается активным SELECT. Так что Ваши заявления, что SELECT блокирует именно данные не правильные.
...
Рейтинг: 0 / 0
17.11.2004, 19:29
| Ответить | Цитировать | Написать  
блокировка selectом
    #32789115
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Чего ж ты хочешь, truncate вообще монопольный доступ к таблице должен получить для работы.
А если не нравиться, что SELECT блокирует - переходи на DBase, там ничего не блокируется. (ну ладно, не пререходи, просто уровень изоляции транзакций выстави в 0).
Но truncate впаралель с чет-то еще полюбому не пойдет.
...
Рейтинг: 0 / 0
18.11.2004, 13:46
| Ответить | Цитировать | Написать  
Период между сообщениями больше года.
блокировка selectом
    #34047943
Фотография A.K.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
A.K.
Участник
Немного другой вопрос, связанный с блокировками. ASA 8.03

Пишу систему, в которой необходимо в одном месте организовать строго последовательный доступ к строкам одной таблицы (A_LORRIES) на их изменение. При этом изменение других строк той же таблицы допускаться должно.
В принципе, все получилось, но не нравится каким образом (программа пишетсяя на Delphi):

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
 // Где-то выше создан такой запрос: 
 // Query1.SQL.Text := 'update A_LORRIES set LORRYID = :LORRYID1 where LORRYID = :LORRYID2'; 

   try 
    DataModule1.ExecuteSQL('SET TEMPORARY OPTION ISOLATION_LEVEL = 3;');
    DataModule1.ExecuteSQL('SET TEMPORARY OPTION BLOCKING = OFF; ');
    Query1.ParamByName('LORRYID1').Value := MyID;
    Query1.ParamByName('LORRYID2').Value := MyID;
     try 
      Query1.ExecSQL();

      ShowMessage('Все прекрасно!');
       //... Идем дальше... 
     except 
      on E: EDBEngineError  do 
         if  Pos('Serialization failure', E.Message)> 0   then   begin 
          ShowMessage('Сюда сейчас нельзя!')
         end 
         else 
           raise ;
     end ;

   finally 
    DataModule1.ExecuteSQL('SET TEMPORARY OPTION ISOLATION_LEVEL = 1;');
    DataModule1.ExecuteSQL('SET TEMPORARY OPTION BLOCKING = ON; ');
   end ;

Вопрос: Нельзя ли выполнить проверку блокировки без UPDATE'а? Почему не получается проверить блокировку при запросе вида SELECT ... FOR UPDATE ?
Сорри за детские вопросы, раньше работал с другой СУБД, где другие средства работы с блокировками и модель выполнения конкурентных транзакций.
...
Рейтинг: 0 / 0
11.10.2006, 16:14
| Ответить | Цитировать | Написать  
блокировка selectом
    #34052801
Фотография A.K.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
A.K.
Участник
Господа, ну неужели никто не подскажет? (см. вопрос выше).
Как в ASA8 правильно установить эксклюзивную блокировку записи на определенные строки определенной таблицы?
При этом необходимо, чтобы СУБД не ждала освобождения заблокированного ресурса, а генерировала исключение (ну с этим-то все вроде бы ясно, BLOCKING=OFF и начинает работать именно так).

В вышеприведенном коде у меня вызывает сомнения текст запроса Query1, который выполняется исключительно с целью установления блокировки, - можно ли установить блокировку, не производя там "вырожденный" UPDATE?
...
Рейтинг: 0 / 0
13.10.2006, 10:43
| Ответить | Цитировать | Написать  
блокировка selectом
    #34052964
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
A.K.Господа, ну неужели никто не подскажет? (см. вопрос выше).
Как в ASA8 правильно установить эксклюзивную блокировку записи на определенные строки определенной таблицы?
При этом необходимо, чтобы СУБД не ждала освобождения заблокированного ресурса, а генерировала исключение (ну с этим-то все вроде бы ясно, BLOCKING=OFF и начинает работать именно так).

В вышеприведенном коде у меня вызывает сомнения текст запроса Query1, который выполняется исключительно с целью установления блокировки, - можно ли установить блокировку, не производя там "вырожденный" UPDATE?
Если требуется только блокировка строк от записи до окончания транзакций, то вообще то просто делайте:
Код: plaintext
1.
2.
SELECT Count(*)
FROM <Таблица> WITH (REPETABLEREAD)
WHERE <УсловияБлокировки>;
На выбранные записи будет наложена блокировка, запрещающая изменение этих записей, однако позволяющая читать эти записи другим сессиям. Если хочется, чтобы эти записи вообще даже никто не мог прочитать, то для ASA 9 можно хинтом вместо REPEATABLEREAD поставить XLOCK, для ASA 8 только сделать "холостой" UPDATE этих записей.
...
Рейтинг: 0 / 0
13.10.2006, 11:23
| Ответить | Цитировать | Написать  
блокировка selectом
    #34053109
Фотография A.K.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
A.K.
Участник
ASCRUS
Большое спасибо, более-менее разобрался теперь.
А можно ли как-то ПРОВЕРИТЬ наличие блокировки записи на определенные строки таблицы без холостого UPDATE'а?
...
Рейтинг: 0 / 0
13.10.2006, 12:01
| Ответить | Цитировать | Написать  
блокировка selectом
    #34053186
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
A.K. ASCRUS
Большое спасибо, более-менее разобрался теперь.
А можно ли как-то ПРОВЕРИТЬ наличие блокировки записи на определенные строки таблицы без холостого UPDATE'а?
Ну на 9-ке XLOCK все делает. Для 8-ки видимо больше никак не проверишь. Кстати встречный вопрос - для чего нужны эти блокировки ? В чем суть ТЗ - ведь вполне может быть, что Вы ищите реализацию там, где нужно просто другое решение. Спрашиваю потому, что немного непривычно видеть, что кто то пытается с клиентского приложения управлять блокировками, обычно я к примеру выношу это на откуп серверной логике, а в клиентском приложении максимум только управляю собственными логическими блокировками, которые только регулируют какие документы кем открыты, чтобы не было параллейного изменения множества документов. Все остальное считаю нужным выносить исключительно в серверную логику на уровень ХП и триггеров.
...
Рейтинг: 0 / 0
13.10.2006, 12:16
| Ответить | Цитировать | Написать  
блокировка selectом
    #34053331
Фотография A.K.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
A.K.
Участник
ASCRUS
Ну на 9-ке XLOCK все делает. Для 8-ки видимо больше никак не проверишь. Кстати встречный вопрос - для чего нужны эти блокировки ? В чем суть ТЗ - ведь вполне может быть, что Вы ищите реализацию там, где нужно просто другое решение. Спрашиваю потому, что немного непривычно видеть, что кто то пытается с клиентского приложения управлять блокировками, обычно я к примеру выношу это на откуп серверной логике, а в клиентском приложении максимум только управляю собственными логическими блокировками, которые только регулируют какие документы кем открыты, чтобы не было параллейного изменения множества документов. Все остальное считаю нужным выносить исключительно в серверную логику на уровень ХП и триггеров.

Совершенно согласен насчет максимального вынесения логики на сервер. Я как раз и управляю "логическими" блокировками. Если очень упрощенно - есть документ (таблицы: Документ и Комплектация_документа). Необходимо запретить одновременное редактирование документа и его комплектации несколькими пользователями. Пользователь должен получать сообщение, что документ невозможно изменить, т.к. он редактируется другим пользователем, и после этого получать его в режиме read-only.
При этом еще стоит задача коммитить все изменения только по закрытию окна, а в этом окне есть отфильтрованный список документов (их немного) и панель его просмотра/редактирования. Т.е. пользователь может там неизменять десяток документов, перекинуть комплектацию с одного на другой, а потом передумать и вернуть все как было, или сохранитиь всё.

Если у вас есть свое видение по данной теме, с радостью приму его к сведению.
...
Рейтинг: 0 / 0
13.10.2006, 12:46
| Ответить | Цитировать | Написать  
блокировка selectом
    #34053401
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Гм, ну тогда с этого и нужно было начинать вообще то :) Почему я на всякий случай и спросил - тема обсуждаемая уже тысячу раз, но каждый раз кто то снова пытается придумать велосипел, причем обязательно с квадратными колесами на блокировках сервера.

Поясняю вкратце:
Нельзя задачу проверки на запрет одновременного изменения документов в клиентской части решать с помощью физических блокировок СУБД. Блокировки на сервере служат не для этого, а для того, чтобы гарантировать целостность проведения транзакции до ее подтверждения на различных уровнях изоляции сессии. Поэтому пользуясь такими блокировками в своих целях мы получим настоящий однопользовательский сервер, где один человек открывает документ, вешает блокировку на него на сервере, а все остальные уже не могут из за этой блокировки не считать, не изменить никакие записи этой таблицы, так как будут постоянно спотыкаться об эту блокировку.

Поэтому для таких задач нужно пользоваться виртуальными блокировками. Суть их проста до невозможности:
1. делаем табличку Блокировки с полями ИмяТаблицы, КодЗаписи, КодСессии, ЛогинЮзера, ДатаУстановкиБлокировки
2. делаем хранимую процедуру с параметрема ИмяТаблицы, КодЗаписи, ФлагЗаблокировать, которая в зависимости от флага или снимает поставленную в табличку Блокировки запись блокировки или же проверяет, что еще записи нет и устанавливает свою, записав ее в табличку (естественно иначе генерится ошибка, что кто то раньше установил блокировку)
3. опциально - делаем триггер на таблицы, который генерит ошибку, если идет попытка изменения записи, которая присутствует в табличке Блокировки под кодом другой сессии.
4. пишем событие на логофф сессии, в котором просто на всякий пожарный удаляем все блокировки, которые принадлежат отключаемой сессии, чтобы при отвале сети другие не страдали от блокировок
5. в клиентской части честно на открытие формы редактирования вызываем ХП с попыткой заблокировать запись, при закрытии формы вызываем ХП для того, чтобы удалить блокировку

У меня эта схема написана на PB и работает идеально. Правда без пункта 3, изменения производятся централизованно только через одно клиентское приложение и смысл жестко контролировать в БД изменения таблиц нету, достаточно того, что клиентское приложение само вызывает и снимает блокировки. Естественно в пунктах 2 и 4 в конце кода ХП стоит COMMIT. Никаких физических блокировок на момент редактирования документа нет, соотвествующе и простоев других сессий тоже нет - все работает замечательно.

--
www.rusug.ru - портал русскоязычной группы пользователей Sybase
...
Рейтинг: 0 / 0
13.10.2006, 13:01
| Ответить | Цитировать | Написать  
блокировка selectом
    #34053413
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
A.K.При этом еще стоит задача коммитить все изменения только по закрытию окна, а в этом окне есть отфильтрованный список документов (их немного) и панель его просмотра/редактирования. Т.е. пользователь может там неизменять десяток документов, перекинуть комплектацию с одного на другой, а потом передумать и вернуть все как было, или сохранитиь всё.
Та же ситуация - совершенно неверное использование транзакции, что приведет к запрету работы других сессий. Для таких целей нужно не в транзакции изменения держать на сервере, а на клиентском приложении проводить отложенные (пакетные) изменения, где пользователь может что угодно делать с информацией, но изменения только кэшируются на клиентском приложении и будут пакетно выкладываться на сервер в пределах одной транзакции по подтверждению пользователем ввода информации. Почти все платформы так или иначе поддерживают режим отложенных изменений, а Ваш метод превращает многопользовательский РСУБД в однопользовательский DBF :)
...
Рейтинг: 0 / 0
13.10.2006, 13:04
| Ответить | Цитировать | Написать  
блокировка selectом
    #34053526
Фотография A.K.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
A.K.
Участник
ASCRUSТа же ситуация - совершенно неверное использование транзакции, что приведет к запрету работы других сессий. Для таких целей нужно не в транзакции изменения держать на сервере, а на клиентском приложении проводить отложенные (пакетные) изменения, где пользователь может что угодно делать с информацией, но изменения только кэшируются на клиентском приложении и будут пакетно выкладываться на сервер в пределах одной транзакции по подтверждению пользователем ввода информации. Почти все платформы так или иначе поддерживают режим отложенных изменений, а Ваш метод превращает многопользовательский РСУБД в однопользовательский DBF :)

Постараюсь учесть все вышесказанное, хотя в моем конкретном случае причин возникновения многих из описанных проблем не вижу.
Блокировка при редактировании накладывается только на одну строку одной таблицы (шапка Документа), и только на запись. Редактирование остальных (Комплектации документа) ведется через временную таблицу, которая затем, перед закрытием окна с сохранением изменений, пакетно обрабатывается в ХП.
Наличие "длинных" транзакций в данном случае не приведет к блокировке всех и всего, т.к. изменяются преимущественно временные таблицы.

Плюс к тому есть еще один момент. Я пишу доп. модуль к уже работающей системе и на введение таблицы учета "виртуальных" блокировок этой системе будет начихать асболютно.

А чтобы превратить РСУБД в DBF, надо наверное блокировать таблицы целиком и на чтение :-)) Разве ASA не поддерживает блокировки на уровне конкретной строки?
...
Рейтинг: 0 / 0
13.10.2006, 13:25
| Ответить | Цитировать | Написать  
блокировка selectом
    #34053573
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Ну так насколько я понял вы блокируете строку эклюзивной блокировкой (иначе вообще какой смысл накладывать шаред блокировку, если все кому не лень могут читать и начинать редактировать документ). Как Вы думаете, простой запрос SELECT COUNT(*) FROM Table что сделает при встрече одной эклюзивно заблокированной записи ? Или будет ждать доброго юзера, пока он не соизводит закрыть редактируемый документ или вышибется с ошибкой, что будет нонсенсом для пользователя, который делал отчет и считал к примеру кол-во документов. Как раз и получится монопольная система.

--
www.rusug.ru - портал русскоязычной группы пользователей Sybase
...
Рейтинг: 0 / 0
13.10.2006, 13:34
| Ответить | Цитировать | Написать  
блокировка selectом
    #34053643
Фотография A.K.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
A.K.
Участник
ASCRUSНу так насколько я понял вы блокируете строку эклюзивной блокировкой (иначе вообще какой смысл накладывать шаред блокировку, если все кому не лень могут читать и начинать редактировать документ). Как Вы думаете, простой запрос SELECT COUNT(*) FROM Table что сделает при встрече одной эклюзивно заблокированной записи ? Или будет ждать доброго юзера, пока он не соизводит закрыть редактируемый документ или вышибется с ошибкой, что будет нонсенсом для пользователя, который делал отчет и считал к примеру кол-во документов. Как раз и получится монопольная система.

1) В приведенном примере select count(*) - естественно подвиснет.

2) Нет, я не накладываю эксклюзивную блокировку чтения. Я делаю то, что выше приведено кодом. Получается проверка наличия блокировки записи. Если блокировки нет, она устанавливается холостым UPDATE. Если блокировка есть, то холостой UPDATE позволяет узнать о ее наличии и запретить переход в режим редактирования. Не время этой проверки для сессии изменяется уровень изоляции с 1 на 3 и опция BLOCKING, после чего все возвращается обратно.
...
Рейтинг: 0 / 0
13.10.2006, 13:48
| Ответить | Цитировать | Написать  
блокировка selectом
    #34053676
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Нет такого понятия, как эклюзивная блокировка чтения. Есть просто эклюзивная блокировка. Если Вы делаете UPDATE и после него сразу не делаете COMMIT/ROLLBACK, то на записи будет висеть X-блокировка, которую не смогут прочитать читатели и изменить писатели. Соотвествующе все читающие таблицу сессии будут просто на этой записи зависать.
--
www.rusug.ru - портал русскоязычной группы пользователей Sybase
...
Рейтинг: 0 / 0
13.10.2006, 13:57
| Ответить | Цитировать | Написать  
блокировка selectом
    #34053754
Фотография A.K.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
A.K.
Участник
ASCRUSНет такого понятия, как эклюзивная блокировка чтения. Есть просто эклюзивная блокировка. Если Вы делаете UPDATE и после него сразу не делаете COMMIT/ROLLBACK, то на записи будет висеть X-блокировка, которую не смогут прочитать читатели и изменить писатели. Соотвествующе все читающие таблицу сессии будут просто на этой записи зависать.


При установленном в других сессиях ISOLATION_LEVEL = 1 (это рекомендация разработчика системы) ? Что-то не наблюдаю у себя такого.

Вообще, объясню почему начал делать именно так. Работал с Oracle.
Там если предполагается обновление данных, то чтобы избежать их изменений другими сессиями между считыванием исходных данных и записью измененных, при считывании ставится select ... for update. В результате накладывается блокировка, запрещающая всем остальным писать что-то в выбранное таким селектом. Затем по закрытию транзакции все освобождается.

Теперь про кэширование и пакетную обработку. Работаю в delphi, что же мне теперь - множество строк из БД загонять вручную в какие-то структуры данных клиента (записи, коллекции,...) а потом их в конце "перерабатывать"? Единственно реальное решение вижу в выборке во временную таблицу, работе с этой таблицей стандартными средствами Delphi, а затем пакетной обработке этой таблицы черех вызываемую перед commit ХП.
...
Рейтинг: 0 / 0
13.10.2006, 14:15
| Ответить | Цитировать | Написать  
блокировка selectом
    #34053859
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Оракл это версионник, ASA это блокировочник - абсолютно по разному работают. Рекомендую для начала все таки начальную базовую документацию почитать о принципах работы блокировочников, уровнях изоляций ASA и т.д. (можно почитать еще рассылку и материалы с http://www.rusug.ru ).

Кэширование в Delphi еще с времен BDE штатно присутствует, думаю компонент TUpdateSQL не просто так с первых версий Delphi в VCL присутствовал ;) Для ADO/saVCL так же есть аналоги штатных кэшированных изменений. Не понимаю, зачем Вам что то кэшировать в свои структуры.

P.S. Не обижайтесь, но на лицо явные пробелы в знаниях ASA и Delphi. Думаю Вам любой скажет что при таких подходах хорошего решения у Вас не получится - нельзя программировать на том, чего не знаешь (или еще хуже, когда программируя так, как на том что раньше знал). Потратьте пару дней, почитайте документацию, поэксперементируйте, узнайте о возможностях ASA/Delphi, а потом уже вместо того, чтобы прикручивать решение "как на Оракле", просто увидите другие способы решения задач и будете не прикручивать, а мягко использовать как правильно для "ASA" ;)

--
www.rusug.ru - портал русскоязычной группы пользователей Sybase
...
Рейтинг: 0 / 0
13.10.2006, 14:41
| Ответить | Цитировать | Написать  
блокировка selectом
    #34054178
Фотография A.K.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
A.K.
Участник
Обижаться точно не буду :-) Потому и спрашиваю, что в ASA нет опыта.
За ссылки спасибо, т.к. когда читаешь оригинальную документацию на инглише, какие-то моменты можно и упустить.
А сбило меня с толку то, что стандартный TQuery (Delphi 5) у меня почему-то чихает на текущее значение ISOLATION_LEVEL для TDatabase и выполняет все запросы в режиме ISOLATION_LEVEL=0. Соответственно, нежелательных блокировок в результате и не возникало. Стоило внутри TQuery написать перед запросом 'set temporary option isolation_level=1', как получилась именно та однопользовательская СУБД, которую вы и обещали.
...
Рейтинг: 0 / 0
13.10.2006, 16:11
| Ответить | Цитировать | Написать  
блокировка selectом
    #34055183
Фотография Анатолий Иванов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Анатолий Иванов
Участник
ASCRUSПоэтому для таких задач нужно пользоваться виртуальными блокировками. Суть их проста до невозможности:
...

Я бы еще добавил пункт с удалением всех блокировок текущего пользователя при его логине, т.к. может быть ситуация, когда сервер просто упадет (ну да, бывает и такое, хотя и очень редко) и тогда логофф-скрипт не отработает и не очистит блокировки этого пользователя.
Кстати, на каком уровне изоляции это все предполагается?
...
Рейтинг: 0 / 0
14.10.2006, 15:58
| Ответить | Цитировать | Написать  
блокировка selectом
    #34056048
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Анатолий Иванов ASCRUSПоэтому для таких задач нужно пользоваться виртуальными блокировками. Суть их проста до невозможности:
...

Я бы еще добавил пункт с удалением всех блокировок текущего пользователя при его логине, т.к. может быть ситуация, когда сервер просто упадет (ну да, бывает и такое, хотя и очень редко) и тогда логофф-скрипт не отработает и не очистит блокировки этого пользователя.
Гм - есть такое событие на старт БД - просто забыл перечислить :)

Анатолий ИвановКстати, на каком уровне изоляции это все предполагается?
На любом - ведь блокировка изменения документа пишется в отдельную таблицу и транзакция закрывается. Так что все читающие сессии продолжают работать как ни в чем не бывало и видеть оригинальную редактируемую информацию, при четком конечно условии, что на клиентском приложении используются кэшируемые/пакетные изменения и клиентское приложение или сохраняет все, снимая блокировку, или откатывает все и продолжает редактирование или снимает блокировку, отказываясь от редактирования.
...
Рейтинг: 0 / 0
16.10.2006, 07:34
| Ответить | Цитировать | Написать  
блокировка selectом
    #34240069
Timo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Timo
Участник
ASCRUS
Поэтому для таких задач нужно пользоваться виртуальными блокировками. Суть их проста до невозможности:
1. делаем табличку Блокировки с полями ИмяТаблицы, КодЗаписи, КодСессии, ЛогинЮзера, ДатаУстановкиБлокировки
2. делаем хранимую процедуру с параметрема ИмяТаблицы, КодЗаписи, ФлагЗаблокировать, которая в зависимости от флага или снимает поставленную в табличку Блокировки запись блокировки или же проверяет, что еще записи нет и устанавливает свою, записав ее в табличку (естественно иначе генерится ошибка, что кто то раньше установил блокировку)
3. опциально - делаем триггер на таблицы, который генерит ошибку, если идет попытка изменения записи, которая присутствует в табличке Блокировки под кодом другой сессии.
4. пишем событие на логофф сессии, в котором просто на всякий пожарный удаляем все блокировки, которые принадлежат отключаемой сессии, чтобы при отвале сети другие не страдали от блокировок
5. в клиентской части честно на открытие формы редактирования вызываем ХП с попыткой заблокировать запись, при закрытии формы вызываем ХП для того, чтобы удалить блокировку
--


А не могли бы Вы разместить код ХП. Или выслать на shvt@yandex.ru. В Sybase опыта никакого, как и в клиент-серверных приложениях. А надо.
...
Рейтинг: 0 / 0
07.01.2007, 09:54
| Ответить | Цитировать | Написать  
блокировка selectом
    #34244207
Фотография A.K.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
A.K.
Участник
Пример возможной реализации в MS SQL Server можно найти поиском по форуму.
Идея в целом та же самая, нюансы касаются в основном способа снятия блокировок, установленных отмершими коннектами и явно не снятыми, с поправкой на различия в возможностях ASA и MSSQL.
...
Рейтинг: 0 / 0
09.01.2007, 22:20
| Ответить | Цитировать | Написать  
22 сообщений из 22, страница 1 из 1
Форумы / Sybase ASA, ASE, IQ [игнор отключен] [закрыт для гостей] / блокировка selectом
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]