> User1 редактирует Вася на Петя
> User2 редактирует Петров на Иванов

почему два юзера работают с одной записью?

> rrrrrrr ©   (07.09.17 18:25) [19]

не понял вас

exec proc UpdateT1
@id = 1,
@OldF1 = Вася, @OldF2=Петров,
@NewF1 = Петя, @NewF2=Васев

в проце смотрим, актуально ли F1 = Вася и F2=Петров
если да - меняем, ничего не возвращаем

если нет - возвращаем датасет, который показываем юзеру
пусть, кто-то изменил  F1 = Коля
показываем, что ты молодец, но вот Вася, который ты хотел сделать Петей, стал уже Колей.
Он выбирает вариант и опять дергает обновление

exec proc UpdateT1
@id = 1,
@OldF1 = Коля, @OldF2=Петров,
@NewF1 = Петя, @NewF2=Васев

и нет никаких блокировок

> почему два юзера работают с одной записью?

по разному

может, неправильно разделили работу, пересеклись внутри отдела
может, разные отделы в меру компетенции меняют разные части одной записи

> ВладОшин ©   (07.09.17 19:49) [22]

а программист тут причем?

Удалено модератором

не понял вас

чего там понимать.
выше предлагали локать тому кто первый, а всех остальных отваливать.

что-то типа ораклового селект форапдейт новейт.

и тогда вася открывает запись на редактирование, все кто после получают исключение и в редактирвание не входят.

но тут разрабу звонят снова,
и говорят, что нам срочно надо отредактировать это, а вася ушел за печенюшками.
и будет через полчаса.

Удалено модератором

> Дмитрий   (07.09.17 14:45) [12]
>
>
> > Так два или "стописят"?
>
> На практике, одновременно запись может быть открыта у 3-
> 6 пользователей.
>

Тогда о такой "блокировке" стоит забыть сразу и навсегда.
И тем более навсегда забыть о методе TDataset.post.

> Игорь Шевченко ©   (06.09.17 18:24) [6]
>
> > Какое решение наработали практика и теория?
>
>
> Административное.

Сначала поиздеваемся над пользователями, а потом еще и накажем.

to Дмитрий   [16]&[17]
У вас работа с базой идет через приложение?  Или юзеры напрямую с ней могут работать?
Во втором случае нужно использовать еще и административные ресурсы: запретить юзерам прямые вставки/обновления/удаления и делать это через хранимые процедуры.
Блокировка записи - это условность, которую нужно обрабатывать. Т.е. через Get_Lock задаете имя блокировки MyTable_ID100500, если блокировка ставится - редактируем, если нет - говорим юзеру что бы подождал.
После сохранения выполняем Release_Lock с тем же именем.
Если клиент установивший блокировку отваливается (вырубили комп или кикнули на серваке) - блокировка автоматом снимается.
Рекомендую все же почитать документацию по MySQL.

rrrrrr ©   (07.09.17 21:08) [25]
Если кто-то локнул запись и ушел...
Есть 2-варианта:
1. У Get_Lock в качестве 2-го параметра задается таймаут (0 - бесконечно).
2. Для каждого пользователя в MySQL заводится отдельная учетка. Ушел человек, зашли в консоль и кикнули. Все продолжают работать.

> зашли в консоль и кикнули.

кто зайдет? бабулька из бухгалтерии? или всё это справедливо для фирм с кучей "айтишников", а остальные мелкие нас неинтересуют?

Ну если контора находится в дикой глуши, без инета, куда на одних оленях ехать суток 7, делегировать часть административного ресурса кроме медведей некому, то да, это проблема...
Вы создаете проблему из ничего. Есть масса способов как сделать это.
А кикнуть можно же не только через консоль, это же можно и в виде административного интерфейса реализовать.

Ушел человек, зашли в консоль и кикнули.

Вы создаете проблему из ничего.

Это именно ты создал проблему из ничего.

когда юзер узнает про ошибку в конце редактирования и идет к программеру, то программер ему говорит: вы там договоритесь чье есть чье и не полоскайте мне моск.

а когда этот погромист типа макроденса ввел локи, то к программеру все равно приходят,
но теперь он вместо того, чтобы ничего не делать, ищет блокировки и снимает их.

итого:

было: недовольство юзеров и ничего не надо было делать.
стало: недовольство юзеров, но делать что-то надо.

это же можно и в виде административного интерфейса реализовать.
программизм ради программизма.

> Вы создаете проблему из ничего.
проблема в логике... твоей.

> Есть 2-варианта:
1 вариант, все остальное приводит к костылям типа нужного админа/администрирования не сервера, а обслуживания самой логики.
клиент должен прочитать запись/список/..., и отключится от сервера/или просто не мешать всякими левыми блокировками. запись редактируется на клиенте сколь угодно долго, хоть месяц, не связано с сервером вообще. после редактирования сохраняется (кнопку нажали) - подключаемся - локируем если нужно - сохраняем или отменяем при ошибке, завершаем действие или откатываемся на окно редактирования. все локирование занимает минимум времени, на момент записи.
если боимся, что кто-то уже редактировал и написал туда уже что-то "гениальное", то вводим проверочное поле типа таймeстамп и проверяем по нему было ли редактирование кем-то другим с момента чтения (не совпадут если было). было, значит показываем измененные данные и спрашиваем "перезаписать?"
через месяц, два всех так достают все время всплывающие вопросы о перезаписи что просят убрать (административно то не задали правил, и все редактируют одно и то же)... приходим к варианту "кто последний тот и прав". конец.

или всё это справедливо для фирм с кучей "айтишников",

в одной конторе решили в электронный документооборот и эцп.
на документе может стоять несколько подписей.
все классно.

но какой-то вуди почему-то решил, что если на удаляемом документе есть подписи, то удалять его нельзя.

в результате на документе стоит три подписи, и одна из них бабы маши, которой в момент удаления документа (а удалять иногда надо и это нормально) нету на месте.

две подписи уже удалены, а подпись бабы маши удалить никто не может, так как удалить может только владелец (из интерфейса программы конечно)

а документ удалять надо, так как он мешает чему-то  (например закрытию дня)

я говорю менеджерам, вы чего курили, придурки, когда такое придумывали?
у вас по нормальному течению процесса сейчас сам документ должен быть удален,
какая разница, подписан он или нет?

- не, так и должно быть, если подписан, то удалять нельзя.

окей, говорю, раз нельзя, то нельзя. вызывайте бабу машу и пусть отзывает эцп.

- не не не. пока мы ее найдем, все взорвется, "удалите эцп как-нибудь так"

Это именно ты создал проблему из ничего.
Это какую я проблему создал? оповестил юзера, что запись уже редактируется?


а когда этот погромист типа макроденса ввел локи, то к программеру все равно приходят,
но теперь он вместо того, чтобы ничего не делать, ищет блокировки и снимает их.

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


было: недовольство юзеров и ничего не надо было делать.
стало: недовольство юзеров, но делать что-то надо.

Да, я знаю, что есть категория пользователей, которые мечтают о супер кнопке....


программизм ради программизма.

А зачем собственно софт реализовывать? Пусть в базе напрямую работают.

Я считаю, что если базой параллельно начинаю пользоваться больше 1-го юзера - то административные инструменты уже необходимо вводить. И чем раньше, тем проще это будет сделать.


to sniknik ©   (11.09.17 12:15) [33]
1 вариант, все остальное приводит к костылям типа нужного админа/администрирования не сервера, а обслуживания самой логики.

Я с этим соглашусь, если юзеров не больше десятка, а если их сотни?


через месяц, два всех так достают все время всплывающие вопросы о перезаписи что просят убрать (административно то не задали правил, и все редактируют одно и то же)... приходим к варианту "кто последний тот и прав". конец.

А еще через месяц к тебе приходят и говорят, что в данных почему-то каша, что я  точно помню что я менял эти данные и теперь отчеты не сходятся и т.п.
И начинаем заморачиваться по истории изменений (если не как с административными правилами, конечно)

> Я с этим соглашусь, если юзеров не больше десятка, а если их сотни?
тем более. логика должна быть максимально отвязана от необходимости ее админить.

> А еще через месяц к тебе приходят и говорят
ко мне с этим точно не прийдут, я там выше писал про юзера кто последний в редактируемой записи, и историю. и то и то доступно менеджеру/оператору, сами смотрят кто их записи перетер.

еще кстати, раз уж свернули на мою систему, есть настраиваемые права, кому что можно смотреть/редактировать. и чаще всего за определенные данные отвечают/работают с ними по отделам, т.е. люди в шаговой доступности. сами меж собой как то разбираются.

+ если даже наворотили "кашу", то это ИХ проблема. а вот админить и разные заумные схемы реализовывать (через месяц не понятные никому даже постановщику задачи), отвечать за них это ТВОЯ проблема. нафиг. все должно быть максимально просто.

еще кстати, раз уж свернули на мою систему, есть настраиваемые права, кому что можно смотреть/редактировать. и чаще всего за определенные данные отвечают/работают с ними по отделам, т.е. люди в шаговой доступности. сами меж собой как то разбираются.

А это разве не администрирование логики?
То же самое я могу сказать про свою реализацию - есть настраиваемые права для пользователей и они сами решают что делать в рамках правил.

Тут вопрос наверное больше упирается в ТЗ.

> А это разве не администрирование логики?
это не логика, это права
логика это то, что приводит к действиям типа
> Ушел человек, зашли в консоль и кикнули. Все продолжают работать.
сравни с моей... - ушел человек, и хрен с ним. все продолжают работать. пришел, и продолжил, доделал тяжким трудом и одним пальцем, пытается сохранить, а ему сообщение "все уже сделано без вас". лучше же так. и админ с консолью не нужен.

Тут вопрос наверное больше упирается в ТЗ.

нет.
вопрос в том, что реальный мир устроен немного не так, как думает погромист когда пишет свои поделки.

что в [38] еще раз и расжевано.