Запретить открывать форму с данными, если она уже открыта другими

@vadca · Регистрация: 07.04.2016

Студворк — интернет-сервис помощи студентам

Добрый день. Есть список с данными, нажимая 2 раза, открывается форма с этими детальными данными. Там есть идентификационный код или серия. Нужно запретить, открытие формы по идентификационному коду если она уже открыта.

Возможно ?

@Grossmeister · 08.12.2017, 12:50

Сообщение от vadca

Нужно запретить, открытие формы по идентификационному коду если она уже открыта.

Имеется ввиду запрет открытия на другом клиентском месте?

@vadca · 08.12.2017, 13:13 **[ТС]**

Да, на другом ПК или на нескольких.

Добавлено через 20 минут
MS SQL Server база данных

@Grossmeister · 08.12.2017, 13:16

Сообщение от vadca

Да, на другом ПК или на нескольких

Полагаю, что зависит от СУБД.
Например, в Oracle есть конструкция SELECT ... FOR UPDATE. Если я при открытии формы делаю не просто SELECT, а SELECT FOR UPDATE, то СУБД проверяет, не заблокирована ли строка другим. Если заблокирована, то выдается ошибка, которую при обработке можно заменить на что-то вроде "Документ уже открыт другим пользователем".

@Usaga · 08.12.2017, 13:20

Grossmeister, не, это вы уже жестите. Перед выдачей ошибки база знатно потупит (подождёт, пока снимется блокировка). Лучше завести отдельное поле в этой таблице (или в другой) с признаком блокировки записи. Хотя тут придётся следить за снятием этой записи, ибо клиент может отвалиться не почистив за собой запись.

@Grossmeister · 08.12.2017, 13:24

Сообщение от Usaga

Перед выдачей ошибки база знатно потупит (подождёт, пока снимется блокировка)

Нет. Точнее если просто SELECT FOR UPDATE, то да, программа перейдет в ожидание снятия блокировки.
А вот если SELECT FOR UPDATE NOWAIT, то будет попытка самому заблокировать строку, а если она уже заблокирована, то немедленно ORA-00054 resource busy

@Usaga · 08.12.2017, 13:30

Grossmeister, но это если речь о обращении к базе в рамках транзакции. ТС просил удерживать блокировку на всё время открытия формы редактирования. А это значит, что придётся держать транзакцию пока не закроется форма редактирования. Мягко говоря, не очень правильное решение.

И не нужно ли прибавить HOLDLOCK, чтобы блокировка не уехала после выполнения запроса?

@vadca · 08.12.2017, 13:39 **[ТС]**

Спасибо за идеи. Буду пробовать обе.

@Grossmeister · 08.12.2017, 13:50

Сообщение от Usaga

Мягко говоря, не очень правильное решение.

Во-первых, вряд ли кто-то станет специально долго держать открытую форму.
Во-вторых, открытая транзакция ничему не мешает.
В-третьих, если по бизнес-условиям во время редактирования инфы никто другой не имеет права редактировать эту же инфу, то другого способа, кроме как SELECT FOR UPDATE, обеспечить это нет.
А что касаемо самопальной реализации блокировок, то это обязательно будет приводить (хотя бы периодически) к тому, что эти блокировки будут оставаться. Тем более, что для того, чтобы изменение какого-то поля увидела другая сессия, это изменение надо зафиксировать с пом. COMMIT

@Usaga · 08.12.2017, 13:55

Grossmeister, я согласен, что самопальная блокировка - дело такое, за ней следить нужно. Но можно решить и иначе: мьютексами на стороне сервера\клиента.

Удерживать монопольную блокировку над строкой\таблицей - плохое решение.

Добавлено через 54 секунды

Сообщение от Grossmeister

Во-первых, вряд ли кто-то станет специально долго держать открытую форму.

Открыть форму и пойти попить чая или поговорить по телефону с клиентом - чем не распространённая практика?

@vadca · 08.12.2017, 14:04 **[ТС]**

Usaga, а как реализовать мьютексами на стороне сервера\клиента. ? Я мютекс реализовал на саму оболочку программы, чтобы не запускали несколько раз. А тут форма таже, но может содережать разные данные, исходя от серии, наврятли можно наложить мютекс

@Usaga · 08.12.2017, 14:12

vadca, под "мьютексом" я имел в виду общий способ блокирования. Это не обязательно должен быть именно мьютекс или примитив синхронизации. Можно банально завести словарик (Dictionary) в который заталкивать серийный номер (или что у вас там идентифицирует запись) и какой-нибудь ID клиента взявшегося её редактировать.

Поскольку работа с данными идёт через один сервер, централизованно, то он всегда будет в курсе кто и что редактирует. PROFIT. Никаких "долгих" транзакций.

@vadca · 08.12.2017, 14:24 **[ТС]**

А какой нибудь пример, может можно увидеть где нибудь? С этим еще не сталкивался. или по каким критериям гууглить

@Usaga · 08.12.2017, 14:28

vadca, вам недостаточно совета про словарь?

@hoolygan · 08.12.2017, 15:05

Как-то нелогично поставлена задача.
Если делать селект с удержанием, то, чисто теоретически, другой клиент даже реестр не увидит - так как должен получить хотя-бы айдишку с таблицы, где строка отбирается. И получит вечный дедлок в ожидании.
Переспросите заказчика, может быть нужно не давать права сохранять, пока открыта сессия на другой машине? Иначе задача довольно нетривиальная получается с множеством костылей в будущем.

@vadca · 08.12.2017, 15:25 **[ТС]**

hoolygan, ок, как вариант, как запретить сохранять

?

@Usaga · 08.12.2017, 16:05

vadca, вводите в таблицу поле типа timestamp и читаете её вместе со всеми данными, а в момент сохранения, добавляете её к в условию WHERE (update bla-blah where Id=@Id and Version=@Version). При изменении любого поля записи СУБД автоматически изменит и значение этого поля (оно сродни счётчику), потому последующие попытки обновить запись обломятся: версия-то изменилась и Update такую запись не найдёт.

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

Новые блоги и статьи Все статьи Все блоги /
Отправка уведомления на почту при изменении наименования справочника Maks 24.03.2026 Программная отправка письма электронной почты на примере изменения наименования типового справочника "Склады" в конфигурации БП3. Перед реализацией необходимо выполнить настройку системной учетной. . .	модель ЗдравоСохранения 5. Меньше увольнений- больше дохода! anaschu 24.03.2026 Теперь система здравосохранения уменьшает количество увольнений. 9TO2GP2bpX4 a42b81fb172ffc12ca589c7898261ccb/ https:/ / rutube. ru/ video/ a42b81fb172ffc12ca589c7898261ccb/ Слева синяя линия -. . .	Midnight Chicago Blues kumehtar 24.03.2026 Такой Midnight Chicago Blues, знаешь?. . Когда вечерние улицы становятся ночными, а ты не можешь уснуть. Ты идёшь в любимый старый бар, и бармен наливает тебе виски. Ты смотришь на пролетающие. . .	Контроль уникальности заводского номера - вариант №2 Maks 24.03.2026 В отличие от предыдущего варианта добавлено прерывание циклов, также добавлены новые переменные для сохранения контекста ошибки перед прерыванием цикла: Процедура ПередЗаписью(Отказ, РежимЗаписи,. . .
SDL3 для Desktop (MinGW): Вывод текста со шрифтом TTF с помощью библиотеки SDL3_ttf на Си и C++ 8Observer8 24.03.2026 Содержание блога Финальные проекты на Си и на C++: finish-text-sdl3-c. zip finish-text-sdl3-cpp. zip	Жизнь в неопределённости kumehtar 23.03.2026 Жизнь — это постоянное существование в неопределённости. Например, даже если у тебя есть список дел, невозможно дойти до точки, где всё окончательно завершено и больше ничего не осталось. В принципе,. . .	Модель здравоСохранения: работники работают быстрее после её введения. anaschu 23.03.2026 geJalZw1fLo Корпорация до введения программа здравоохранения имела много невыполненных работниками заданий, после введения программы количество заданий выросло. Но на выплатах по больничным это. . .	Контроль уникальности заводского номера - вариант №1 Maks 23.03.2026 Алгоритм контроля уникальности заводского (или серийного) номера на примере нетипового документа выдачи шин для спецтехники с табличной частью, разработанного в конфигурации КА2. Данные берутся из. . .

@vadca 0 / 0 / 0 Регистрация: 07.04.2016 Сообщений: 109

	Запретить открывать форму с данными, если она уже открыта другими 08.12.2017, 12:41. Показов 1768. Ответов 16 Метки нет (Все метки) Добрый день. Есть список с данными, нажимая 2 раза, открывается форма с этими детальными данными. Там есть идентификационный код или серия. Нужно запретить, открытие формы по идентификационному коду если она уже открыта. Возможно ? 0

@vadca 0 / 0 / 0 Регистрация: 07.04.2016 Сообщений: 109
	08.12.2017, 13:13 [ТС]
	Да, на другом ПК или на нескольких. Добавлено через 20 минут MS SQL Server база данных 0

@Usaga 14313 / 9393 / 1355 Регистрация: 21.01.2016 Сообщений: 35,424
	08.12.2017, 13:20
	Grossmeister, не, это вы уже жестите. Перед выдачей ошибки база знатно потупит (подождёт, пока снимется блокировка). Лучше завести отдельное поле в этой таблице (или в другой) с признаком блокировки записи. Хотя тут придётся следить за снятием этой записи, ибо клиент может отвалиться не почистив за собой запись. 0

@Usaga 14313 / 9393 / 1355 Регистрация: 21.01.2016 Сообщений: 35,424
	08.12.2017, 13:30
	Grossmeister, но это если речь о обращении к базе в рамках транзакции. ТС просил удерживать блокировку на всё время открытия формы редактирования. А это значит, что придётся держать транзакцию пока не закроется форма редактирования. Мягко говоря, не очень правильное решение. И не нужно ли прибавить HOLDLOCK, чтобы блокировка не уехала после выполнения запроса? 0

@vadca 0 / 0 / 0 Регистрация: 07.04.2016 Сообщений: 109
	08.12.2017, 13:39 [ТС]
	Спасибо за идеи. Буду пробовать обе. 0

@vadca 0 / 0 / 0 Регистрация: 07.04.2016 Сообщений: 109
	08.12.2017, 14:04 [ТС]
	Usaga, а как реализовать мьютексами на стороне сервера\клиента. ? Я мютекс реализовал на саму оболочку программы, чтобы не запускали несколько раз. А тут форма таже, но может содережать разные данные, исходя от серии, наврятли можно наложить мютекс 0

@Usaga 14313 / 9393 / 1355 Регистрация: 21.01.2016 Сообщений: 35,424
	08.12.2017, 14:12
	vadca, под "мьютексом" я имел в виду общий способ блокирования. Это не обязательно должен быть именно мьютекс или примитив синхронизации. Можно банально завести словарик (Dictionary) в который заталкивать серийный номер (или что у вас там идентифицирует запись) и какой-нибудь ID клиента взявшегося её редактировать. Поскольку работа с данными идёт через один сервер, централизованно, то он всегда будет в курсе кто и что редактирует. PROFIT. Никаких "долгих" транзакций. 0

@vadca 0 / 0 / 0 Регистрация: 07.04.2016 Сообщений: 109
	08.12.2017, 14:24 [ТС]
	А какой нибудь пример, может можно увидеть где нибудь? С этим еще не сталкивался. или по каким критериям гууглить 0

@Usaga 14313 / 9393 / 1355 Регистрация: 21.01.2016 Сообщений: 35,424
	08.12.2017, 14:28
	vadca, вам недостаточно совета про словарь? 0

@hoolygan 360 / 287 / 76 Регистрация: 21.06.2016 Сообщений: 1,115
	08.12.2017, 15:05
	Как-то нелогично поставлена задача. Если делать селект с удержанием, то, чисто теоретически, другой клиент даже реестр не увидит - так как должен получить хотя-бы айдишку с таблицы, где строка отбирается. И получит вечный дедлок в ожидании. Переспросите заказчика, может быть нужно не давать права сохранять, пока открыта сессия на другой машине? Иначе задача довольно нетривиальная получается с множеством костылей в будущем. 0

@vadca 0 / 0 / 0 Регистрация: 07.04.2016 Сообщений: 109
	08.12.2017, 15:25 [ТС]
	hoolygan, ок, как вариант, как запретить сохранять ? 0

@Usaga 14313 / 9393 / 1355 Регистрация: 21.01.2016 Сообщений: 35,424
	08.12.2017, 16:05
	vadca, вводите в таблицу поле типа `timestamp` и читаете её вместе со всеми данными, а в момент сохранения, добавляете её к в условию WHERE (`update bla-blah where Id=@Id and Version=@Version`). При изменении любого поля записи СУБД автоматически изменит и значение этого поля (оно сродни счётчику), потому последующие попытки обновить запись обломятся: версия-то изменилась и Update такую запись не найдёт. Это очень популярный подход. Никаких блокировок. Только пользователя нужно будет известить, что сохранение не удалось так как целевая запись была изменена кем-то другим. 0