Мастера DELPHI, Delphi programming community Рейтинг@Mail.ru Титульная страница Поиск, карта сайта Написать письмо 
| Новости |
Новости сайта
Поиск |
Поиск по лучшим сайтам о Delphi
FAQ |
Огромная база часто задаваемых вопросов и, конечно же, ответы к ним ;)
Статьи |
Подборка статей на самые разные темы. Все о DELPHI
Книги |
Новинки книжного рынка
Новости VCL
Обзор свежих компонент со всего мира, по-русски!
|
| Форумы
Здесь вы можете задать свой вопрос и наверняка получите ответ
| ЧАТ |
Место для общения :)
Орешник |
Коллекция курьезных вопросов из форумов
KOL и MCK |
KOL и MCK - Компактные программы на Delphi
Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / rsdn.org

 
Чтобы не потерять эту дискуссию, сделайте закладку « предыдущая ветвь | форум | следующая ветвь »

уведомление о блокировке записи [D7, XP, 2003]


Дмитрий   (05.09.17 15:37

Два пользователя одновременно просматривают запись, один начинает редактировать.
Как для второго пользователя отследить блокировку записи для редактирования и вывести уведомление?
Либо при начале редактирования первым пользователем, либо при попытке редактирования вторым?
mySQL-myISAM, adQuery


Дмитрий   (05.09.17 15:50[1]

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


DayGaykin ©   (05.09.17 19:47[2]


> mySQL-myISAM

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


Inovet ©   (05.09.17 23:37[3]

> [2] DayGaykin ©   (05.09.17 19:47)

Ага, а для этой колонки или таблицы нужна ещё одна колонка или таблица. И т.д..


Дмитрий   (06.09.17 15:50[4]

Насколько я понимаю, до вызова dataset.post все оба-стописят пользователей могут одновременно увлеченно вносить правки и ... только получив ошибку при сохранении офигевают.

Какое решение наработали практика и теория?


rrrrrrr ©   (06.09.17 17:15[5]

оставь как есть.
сейчас это проблема пользователя.

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


Игорь Шевченко ©   (06.09.17 18:24[6]


> Какое решение наработали практика и теория?


Административное.


sniknik ©   (07.09.17 00:24[7]

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

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


Германн ©   (07.09.17 03:03[8]


> Дмитрий   (06.09.17 15:50) [4]
>
> Насколько я понимаю, до вызова dataset.post все оба-стописят
> пользователей могут одновременно

Так два или "стописят"?
Для "стописят" режим блокировки записи с уведомлением об этом просто нереален.


Германн ©   (07.09.17 03:08[9]

Кроме того. Вызов dataset.post эти "стописят" не используют.


MacroDenS ©   (07.09.17 09:42[10]

А если все же попробовать использовать Get_Lock/Release_Lock?


rrrrrrr ©   (07.09.17 13:01[11]

и што это даст?


Дмитрий   (07.09.17 14:45[12]


> Так два или "стописят"?

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


macrodens ©   (07.09.17 14:51[13]

to rrrrrrr ©   (07.09.17 13:01) [11]
при попытке редактировать ставишь блокировку на запись (лично я в качестве имени блокировки указываю название таблицы + идентификатор записи).
Дальше все просто: если блокировка ставится - значит можно редактировать, если нет - то кто-то уже редактирует - генерим сообщение пользователю. Блокировка автоматически снимается при дисконекте.


macrodens ©   (07.09.17 14:51[14]

to rrrrrrr ©   (07.09.17 13:01) [11]
при попытке редактировать ставишь блокировку на запись (лично я в качестве имени блокировки указываю название таблицы + идентификатор записи).
Дальше все просто: если блокировка ставится - значит можно редактировать, если нет - то кто-то уже редактирует - генерим сообщение пользователю. Блокировка автоматически снимается при дисконекте.


macrodens ©   (07.09.17 14:52[15]

Так же не забываем после "post" снимать блокировку


Дмитрий   (07.09.17 16:42[16]

Тонкий момент, как вы предлагаете блокировать запись?


Дмитрий   (07.09.17 16:43[17]

И как автоматически снимать


ВладОшин ©   (07.09.17 18:21[18]

муторно это все
надо действительно делать административно

Пробовал как-то:

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

например,
Запись - id=1;F1=Вася;F2=Петров
User1 редактирует Вася на Петя и сохраняет - делаем только update F1, не трогаем F2 (это очевидно, но не все компоненты так работают)
User2 редактирует Петров на Иванов и сохраняет - делаем только update F2, не трогаем F1
Если обязанности юзеров не совпадают, проблем не будет.

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

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

Когда заказчику надоело, он сам попросил оставить принцип

> "кто последний тот и папа... т.е. прав"


rrrrrrr ©   (07.09.17 18:25[19]

то кто-то уже редактирует - генерим сообщение пользователю.

и што?

беспокоящее (разраба в конечном итоге) сообщение генерится уже сейчас.

будет другое, но не менее, а более беспокоящее его же сообщение.
и будет он искать блокирующие сессии и снимать их.

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


KilkennyCat ©   (07.09.17 19:46[20]


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

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


ВладОшин ©   (07.09.17 19:47[21]


> 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]


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

по разному

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


KilkennyCat ©   (07.09.17 19:54[23]


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

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


ВладОшин ©   (07.09.17 19:58[24]

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


rrrrrr ©   (07.09.17 21:08[25]

не понял вас

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

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

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

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


ВладОшин ©   (07.09.17 21:16[26]

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


Германн ©   (08.09.17 02:41[27]


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

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


DayGaykin ©   (08.09.17 11:01[28]


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

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


macrodens ©   (11.09.17 10:59[29]

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 заводится отдельная учетка. Ушел человек, зашли в консоль и кикнули. Все продолжают работать.


kilkennycat ©   (11.09.17 11:07[30]


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

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


macrodens ©   (11.09.17 11:24[31]

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


rrrrrrr ©   (11.09.17 12:00[32]

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

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


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

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

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

итого:

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

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


sniknik ©   (11.09.17 12:15[33]

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

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


rrrrrrr ©   (11.09.17 12:17[34]

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

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

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

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

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

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

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

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

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

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


macrodens ©   (11.09.17 13:10[35]

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


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

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


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

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


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

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

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


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

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


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

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


sniknik ©   (11.09.17 14:54[36]

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

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

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

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


macrodens ©   (11.09.17 15:09[37]


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

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

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


sniknik ©   (11.09.17 15:26[38]

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


rrrrrrr ©   (11.09.17 15:32[39]

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

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

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


macrodens ©   (11.09.17 15:39[40]

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


Дмитрий   (11.09.17 15:42[41]

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

В принципе, сейчас рабочие места больменее устаканились, и за несколькими исключениями по полям пересечений ответственности нет.
Поэтому думаю разбить датасет на несколько под каждую рабочую функцию.
Соответственно апдейтиться будут только свои поля с отказом от блокировок.


macrodens ©   (11.09.17 16:20[42]

вопрос в том, что реальный мир устроен немного не так, как думает погромист когда пишет свои поделки.
Да, да. Легче сказать что это проблема пользователей и пусть между собой договариваются "кто чего куды и как" ©Филатов. Сказ по Федота Стрельца.
Хотя не спорю, многие пользователи без альтернативы выбора ко многому привыкают.

что в [38] еще раз и расжевано.
Я что там разжевано? То что пользователю не стоит отвлекаться от работы ни на секунду? Иначе сделают без него?
Так с блокировкой то же так можно, ставим таймаут, не успел отредактировать за 5 минут - иди лесом.

По мне проще уведомить пользователя заранее, нежели слышать тонну мата при отказе сохранения.


rrrrrrr ©   (11.09.17 16:31[43]

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

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

похожий, но противоположный случай описан в [34]
там вместо того, чтобы снести документ (одно нажатие одного пользователя)
запускался процесс (считай время и людей) :
1. юзер не может удалить документ
2. день не закрывается
3. юзер звонит в тп.
4. ни у юзера ни у тп нет функционала удалить подпись которая сделана не на их ключах.
5. тп начинает разбираться в потрохах бд, и выяснять какой делит надо сделать, чтобы удалить эцп и чтобы после этого все не встало колом.
6. через какое-то время эцп удаляется вручную и тп звонит юзеру, чтобы тот продолжил работу.


rrrrrrr ©   (11.09.17 16:34[44]

Так с блокировкой то же так можно, ставим таймаут, не успел отредактировать за 5 минут - иди лесом.

есть одна контора, которая продает софт.
у них именно так и сделано.

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

официальный ответ от них на эту проблему:
- ну так вводите быстрее!


ухты ©   (11.09.17 16:50[45]

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


macrodens ©   (11.09.17 16:51[46]

Так и у меня не останавливается.

А по [34].
Там просто не продумана (не реализована) иерархия подписантов, вот и все.
А с точки зрения безопасности - правильно, что нельзя удалить документ с другими подписями. Таким функционалам должен обладать вышестоящий подписант (или + ко всему сотрудник СБ).
А то прикинь, работаю люди, создают документы, правят их. А какой-то Вася решил
уволиться с "шиком" и поудалял к чертям все доки с чужими подписями. Весело будет?


sniknik ©   (11.09.17 16:52[47]

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


sniknik ©   (11.09.17 16:55[48]

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


KilkennyCat ©   (11.09.17 18:01[49]


> ухты ©   (11.09.17 16:50) [45]

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


rrrrrrr ©   (11.09.17 18:24[50]

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


эцп это не предохранитель от удаления.
это целостность и неотрицание авторства.

а в описанном примере ВСЕ хотели и ВСЕМ объективно было надо аннулировать документ.

в результате документ конечно удалялся,
но вместо ОДНОГО клика ОДНОГО пользователя
на это создавался целый процесс, растянутый во времни и в нем никак не участвовало корпоративное по.
а участовал плскл девелопер в котором делался делит


ухты ©   (11.09.17 18:40[51]


> там более чем достаточно флага
так это и есть блокировка, какая разница как ее назвать


macrodens ©   (12.09.17 08:04[52]

to sniknik ©   (11.09.17 16:52) [47]
Что же у вас за люди-то работают, уходят курить/обедать/итп и пропадают бесследно и без возможности связи?
Может дело больше в организационном вопросе?
А с 1С они видимо совсем не работают, а то заблокируют проводку и пропадут. А админа то же нету... И пошла контора помиру...

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

Я бы посмотрел на менеджеров заполняющих спецификации с тысячами позиций:
Прикинь: пока Вася заполняет свои 500 позиций на поставку оборудования заказчик прислал факс, который перехватил Петя. В факсе просят некие 100 позиций заменить на другие 100. Он открывает спецификацию спокойно все меняет (блокировки же нет, он и не в курсе что Вася пашет как конь). Потом Вася пытается сохранить и оба на - документ уже изменен, скажет - я последний, моя тема рулит. Ну или проверять что изменилось. короче вероятность ошибки возрастает. Но программист-то не причем. Это проблемы пользователей ибо не могут договориться.
В случае с блокировкой, Петя увидит, что Вася уже пашет, подойдет/позвонит и скажет: "Тормози! Спецификация поменялась, вот новая инфа".


macrodens ©   (12.09.17 08:14[53]

to sniknik ©   (11.09.17 16:55) [48]
Восстановить то не проблема, но сколько на это может понадобиться время?
Может просто изначально свести такие случаи к 0?

to rrrrrrr ©   (11.09.17 18:24) [50]
эцп это не предохранитель от удаления.
это целостность и неотрицание авторства.


Да, но в описанном Вами случае явно не просто так сделали невозможность удаления пока все свои эцп не отзовут?
Тут вопрос, опять таки, больше организационный. У кого-то должны быть полномочия на удаление, например у вышестоящего по должности + сотрудник СБ.


macrodens ©   (12.09.17 08:24[54]

to KilkennyCat ©   (11.09.17 18:01) [49]
to ухты ©   (11.09.17 18:40) [51]


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


rrrrrrr ©   (12.09.17 08:50[55]

Да, но в описанном Вами случае явно не просто так сделали невозможность удаления пока все свои эцп не отзовут?

конечно не просто так, а потому что дураки.

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

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

отзыв ЭЦП имеет какой-то смысл если документ как раз не удаляют.

например.

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

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

и вот он уже со следователем говорит не как обвиняемый, а как свидетель.

а если документ удаляется потому что его объективно надо удалить, то пофик вообще сколько там подписей.


macrodens ©   (12.09.17 09:18[56]

Так я и говорю, что в этом случае вопрос именно организационный.
И по всей видимости не до конца решенный.
Тут нужно понимать, какие действия (окромя ограничения на удаление) выполняются при применении эцп.
Если по документу ведутся параллельные работы 2 и более сотрудниками, то давать удалять документ только одному нельзя. Иначе тот же Вася удалит в конце дня 100500 документов за день/неделю/месяц/год, а на утро выясниться что он уже за бугром на ПМЖ.
В суд на Васю конечно подадут, данные восстановят (если с бекапами проблем нет и админа найдут, а то судя по вашим высказываниям у нас в стране с этим явные проблемы, держать штат ати), но сколько на это уйдет времени? Предприятие не остановиться?

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


rrrrrrr ©   (12.09.17 09:43[57]

Если по документу ведутся параллельные работы 2 и более сотрудниками,

вообще не имеет значения.
эцп там внедрили "чтобы экономить бумагу"

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

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

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


rrrrrrr ©   (12.09.17 09:45[58]

а мораль этой басни такова, что есть люди которые не понимают зачем они что-то делают.
ты вот например не понимаешь.


KilkennyCat ©   (12.09.17 09:47[59]


> ухты ©   (11.09.17 18:40) [51]

это не блокировка. это изменение записи по принципу кто первый тот и прав.


macrodens ©   (12.09.17 10:01[60]

to rrrrrrr ©
Ты я смотрю понимаешь больше всех.
Сокращение использования бумажных носителей - это только малая часть электронного документооборота.
Как раз одна из основных идей - исключить попадания "ненужной" бумаги с печатями в шредер. Что бы ответственность не перекладывать не непричастных.
Принял документ - подписался, изменил - подписался, аннулировал - подписался, хочешь удалить - должен еще кроме тебя кто-то подписаться. И тогда вся работа человека прозрачна и никакого "мошенства"...


macrodens ©   (12.09.17 10:14[61]

это не блокировка. это изменение записи по принципу кто первый тот и прав.
Да это изменение записи и в тоже время грубая условная блокировка, при этом нужно следить за отменой или дисконнектом пользователя. Что бы бронь не подвисла.
Но можно и семафор выставить, тогда в самой записе ничего менять не нужно, а ролбек или дисконект отрубят семафор.
А если тетя Глаша открыла сессию и пошла пить чай - то по отрубаем сессию по таймеру бездействия пользователя. Чем выше поток, тем короче время на бездействие.


rrrrrrr ©   (12.09.17 10:21[62]

Сокращение использования бумажных носителей - это только малая часть электронного документооборота.
Как раз одна из основных идей - исключить попадания "ненужной" бумаги с печатями в шредер.


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

"основная цель электрооборота - чтобы в шредер не попало что-то бумажное"

чтоб так тупить лет двадцать учиться надо


macrodens ©   (12.09.17 10:24[63]

Ну так проясни для чего электронный документооборот нужен?


Игорь Шевченко ©   (12.09.17 10:30[64]


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


Как много нам открытий чудных
Готовит просвещенья дух.


sniknik ©   (12.09.17 10:43[65]

чем мельче проблема тем больше обсуждение...


sniknik ©   (12.09.17 11:00[66]

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


macrodens ©   (12.09.17 11:05[67]

О, уже на философию потянуло...
<offtop>
Я как-то читал прикол по поводу как на тематических форумах отвечают на сабж зарубежом и в России.
Зарубежом.
ТС:Как мне запузырыть иконку в трей?
Имя1: Вот так ссыль..
Имя2: Или так ссыль..
ТС: Спасибо помогло.

Как у нас:
ТС:Как мне запузырыть иконку в трей?
Имя1: В гугле забанили?
Имя2: Тема избита... Сто раз одно и тоже...
Имя3: Найми программиста..
Имя4: Делфи вообще умирает...
Далее несколько страниц обсуждения несвязных с сабжем тем и то какой афтар м...
В итоге половину народа банится (включая автора) и вопрос не решен.
</offtop>


macrodens ©   (12.09.17 11:22[68]

Уважаемый sniknik ©, у не надо так переворачивать.
Я неоднократно писал выше какие механизмы можно использовать дабы не привлекать админов.
Могу напомнить:
1. Таймаут сессии.
2. Таймаут бездействия.
3. Обрыв сессии.

Админ (или старший менеджер/кассир/etc) нужен, когда очень срочно нужно отменить. (почему-то в 1С нормально с этим работают и не парятся).

кстати с билетами там не блокировка, там резервирование. по сути другое,
И как это противоречит тому, что я предложил с блокировками? В чем разница-то?

мне кажется я начал понимать - вас коробит слово "блокировка"?
Хорошо, давайте назовем это по другому: Пусть менеджер Вася зарезервировал некий документ на редактирование с последующей отменой или безусловным подтверждением.
Так лучше будет?


sniknik ©   (12.09.17 12:16[69]

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


sniknik ©   (12.09.17 12:21[70]

> почему-то в 1С нормально с этим работают и не парятся
у нас в конторе несколько систем, 1С тоже есть, и это единственная система которую обслуживает 3 админа. конечно, с чего им парится то? даже на телефонию, которая ИМХО сложнее 1С-а один. на самописных, типа моей, вообще нет, хотя основная работа именно на этих самоделках, и народу в них больше.


sniknik ©   (12.09.17 12:34[71]

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

по теме
http://www.sql.ru/forum/166093/dolgie-tranzakcii-korotkie-tranzakcii
не читал, просто нагуглил, но думаю там тоже самое, что здесь... и каждый остался при своем мнении


macrodens ©   (12.09.17 13:19[72]

Да админ необходим, но не жизненно и не для конкретного приложения. Аутсорсер на удаленке вполне справится и раз/два в месяц кикнуть неродивого сотрудника его не напряжет. Так же можно дать права внутри софта кому-то из сотрудников. А к забывчивому сотруднику применить административные действия. Ибо дисциплина должна быть. 1-2 предупреждения и вырабатывается рефлекс. Уходишь - закрой все документы.

Еще раз говорю дело в специфике задачи.
Если в Вашей системе это оптимальный вариант, все работает и все рады - то значит так и надо. Я же не говорю, что блокировки это сверх необходимость и то что без них работа с базой ущербна. Если можно обойтись без них, значит нужно делать без них.

В моем проекте требования другие, мой заказчик не готов тратить время на разборы сотрудников кто из них прав. Поэтому в ТЗ прописано требование не давать другим пользователям редактировать документы, пока кто-то с ним работает. Да можно при этом просматривать документ и его содержимое.


macrodens ©   (12.09.17 13:28[73]

Да тема похожая, и к консенсус там похоже найден.
Собственно примерно тоже самое я в 72 посте говорил.


KilkennyCat ©   (12.09.17 14:26[74]


> Аутсорсер на удаленке вполне справится

это тот же админ.
какая-то постоянная игра терминами, мне непонятная.


А мне интетресно...   (12.09.17 15:03[75]

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


macrodens ©   (12.09.17 15:29[76]

Уважаемый KilkennyCat © непонятно вам, потому что выдираете отдельные фразы из контекста.
Вопрос был про жизненную необходимость админа, а не кто есть "ху".


macrodens ©   (12.09.17 16:00[77]

А мне интетресно...   (12.09.17 15:03) [75]
ну например на производстве мясной продукции, когда оформляются поставки для ретейлеров.
Сопровождающий гос. документ оформляет вет.врач. В программе находятся предварительные заявки для ретейлеров с Н-ым количеством позиций. в момент оформления количество позиций может измениться, + для позиций необходимо заполнить лабораторные исследования и прочую инфу. если вет.врачи начнут работать одновременно над одной заявкой - это потеря времени. Так как распечатать гос.бланк сможет только один из них, соответственно блокируем документ и коллеги понимают, что нужно заниматься уже другим документом. Сделать привязку к ретейлеру тоже не всегда возможно, так как в один момент времени может оформляться целая фура для одного ретейлера, а гос.блан имеет ограничение на количество позиций.


sniknik ©   (12.09.17 21:02[78]

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


Игорь Шевченко ©   (12.09.17 21:41[79]

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


KilkennyCat ©   (12.09.17 23:29[80]


> Игорь Шевченко ©   (12.09.17 21:41) [79]

а стенгазета? )))


Германн ©   (13.09.17 02:22[81]


> KilkennyCat ©   (12.09.17 23:29) [80]
>
>
> > Игорь Шевченко ©   (12.09.17 21:41) [79]
>
> а стенгазета? )))
>  

Стенгазета - это ДА!
Ни с чем не сравнимые ощущения! :)


macrodens ©   (13.09.17 08:12[82]

sniknik ©   (12.09.17 21:02) [78]
А в чем соскок? Или структурные данные это не про Вас?
Документ это структура, которая таки имеет корневую запись.  В ней описаны, как Вы уже догадались, шапка документа и еще много свойств. Все это нужно заполнять. Если два пользователя будут делать это одновременно - то это приведет к потере времени.
Поэтому при открытии документа на редактирование, я блокирую корневую запись документа.
Позиции по документу (товар) тоже являются структурными данными, но их уже блокировать не нужно, так как добавляются/изменяются они при редактировании документа. Одновременное добавление позиций в документ приведет к каше. Так как позиции могут по наименованию и свойствам могут быть идентичными.

Или для Вас запись эта некая безликая область данных в таблице, которую редактируют исключительно из грида?


sniknik ©   (13.09.17 08:30[83]

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

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

или к примеру приемка товара на складах, когда накладная на 100 листах, и товар в нескольких фурах, всегда принимается в 10+- рук (в сколько есть, операторов/кладовщиков).


macrodens ©   (13.09.17 09:00[84]

to sniknik ©   (13.09.17 08:30) [83]
Вы сабж то перечитайте по внимательнее.
Как для второго пользователя отследить блокировку записи для редактирования и вывести уведомление?

Так чем документ не запись? Чем мои посты противоречат теме?
Я описал для ТС как можно сделать блокировку и вывести уведомления. А что предложили вы? Оставить как есть? Пусть пользователи сами решают кто прав? Вы ведете себя ровно как в том приколе.

представить, что в одном кабинете 2 врача тебе дадут, и впишут одновременно 2 справки так невозможно?
И что они прям одновременно тебя осматривают и пишут? Наверное все же очередность то есть.


rrrrrrr ©   (13.09.17 09:16[85]

Я описал для ТС как можно сделать блокировку и вывести уведомления.

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

он как получал какие-то уведомления от ПО, так и продолжает их получать.

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

как же туго доходит.


macrodens ©   (13.09.17 09:23[86]

rrrrrrr ©   (13.09.17 09:16) [85]
Читай первый пост от ТС.


rrrrrrr ©   (13.09.17 09:25[87]

причем заметь, что разное время получения уведомлений - это оно для тебя разное.
а для юзера оно - одно и то же время.

и называется это "мне снова чего-то нельзя в момент когда я это захотел"


macrodens ©   (13.09.17 09:26[88]

И Ви мине таки еще будете говоить про еалии миа?


macrodens ©   (13.09.17 09:27[89]

Давайте разрешим пользователям все и везде, а если что скажем что это их проблемы


rrrrrrr ©   (13.09.17 09:30[90]

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


rrrrrrr ©   (13.09.17 09:31[91]

И Ви мине таки еще будете говоить про еалии миа?

ты же в них ни бум-бум. конечно буду


macrodens ©   (13.09.17 09:37[92]

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


rrrrrrr ©   (13.09.17 09:40[93]

мое предложение не делает ситуацию хуже.
твое - делает.


macrodens ©   (13.09.17 09:42[94]

Кстати, сегодня праздник...
Разрешил пользователям вводить 100 символов в поле размерностью 50 :-), пусть порадуются, и уведомление о превышении убрал... Гулять так гулять!


rrrrrrr ©   (13.09.17 09:44[95]

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

в то время как юзер хочет внести правки.

в терминах реального мира.
чел лежит на диване и хочет пить.
но в кране нет воды.
ты (как истинный погромист) связываешь ему ноги и присылаешь смс'ку : 'не ходи на кухню, в кране нет воды'

а должен был сделать так, чтобы он эту воду получил.

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


macrodens ©   (13.09.17 09:45[96]


мое предложение не делает ситуацию хуже.
твое - делает.

Чем же?


macrodens ©   (13.09.17 09:51[97]


в терминах реального мира.
чел лежит на диване и хочет пить.
но в кране нет воды.

А если так
Ты подходишь к куллеру налить воды, но в этот момент там набирает воду Маша. А краник один. по твоей логике нужно Машу вышвырнуть ибо не успела налить себе, а кто последний подошел тот и прав. Да? Ты же в этот момент хочешь пить и все остальные побоку?


rrrrrrr ©   (13.09.17 09:51[98]

тупому обычно хватает два раза объяснить и он врубается.
а тебе?


macrodens ©   (13.09.17 09:52[99]

Взаимно


sniknik ©   (13.09.17 10:24[100]

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

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


macrodens ©   (13.09.17 10:46[101]

именно на это был дан ответ не блокировать. вернее ряд ответов...
в том числе и мой, как именно заблокировать и как отследить, что заблокировано.

типа не давать одну и ту же работу разным людям противоречите сами себе sniknik ©   (13.09.17 08:30) [83]

Представьте себе работу какого либо центра обработок заявок, когда заявки в базу попадают автоматизировано (через модули СРМ например, могут поступать заявки с факса, эл.почты, веб.формы и т.п.).
количество заявок ~1000 в час.
Их обрабатывает 100 человек в 10 офисах. Фильтруют, что спам, а что принесет реальные деньги.
Как им не дать выполнять одну и туже работу? Если это и есть их работа? Как сократить впустую потраченное время, если кто последний, тот и прав?


sniknik ©   (13.09.17 11:38[102]

> Представьте себе работу какого либо центра обработок заявок ...
а чё представлять? я в таком участвовал. был эксперимент в институте еще по приему заявок абитуриентов. не знаю чем чем там кончилось, собственно эксперимент был не в приеме заявок, а в электронном вводе сканированием специальной формы.

так, что могу сказать... ввод идет потоком, даже явно дублирующиеся заявки без поиска "а нет ли уже такой?" вводятся как разные. если и нужно, что поправить то только в только что введенной, именно в ней а не в найденной поиском аналогичной, с возможно однофамильцем, а не дублем. дубли убираются уже потом, на распределении при участии и подсчете уже студентов.
тут если честно вообще любой принцип пойдет, т.к. в этом случае 99.9% новые записи, и не правятся вообще. но вот блокировать и тут бы не стал, просто потому что мало ли что, а блокировка может парализовать работу (если какая-нибудь неприятность может случиться(есть возможность), она случается. © Мерфи), причем в самое "горячее" время.


macrodens ©   (13.09.17 12:43[103]

Студенческий эксперимент - это конечно хорошо. Но он не упирается в деньги, и если сотня студентов будет обрабатывать один скан - цена времени не существенна.
В реальном бизнес-процессе это уже может грозить убытками, так как 99% времени будет потрачено впустую. И даже если кто-то пойдя курить/обедать/спать заблокирует заявку - это будет менее накладно (в конечном счете часть издержек могут перенести на сотрудника, в виде лишения премии). Добавим функционал анлока по таймеру бездействия сотрудника - и издержки становятся минимальными.


KilkennyCat ©   (13.09.17 12:51[104]


> И даже если кто-то пойдя курить/обедать/спать заблокирует
> заявку - это будет менее накладно (в конечном счете часть
> издержек могут перенести на сотрудника, в виде лишения премии).
>  Добавим функционал анлока по таймеру бездействия сотрудника
> - и издержки становятся минимальными.

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

таймер бездействия особенно умиляет.


> rrrrrrr ©   (13.09.17 09:44) [95]

отличная аналогия!)


kilkennycat ©   (13.09.17 12:53[105]

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


macrodens ©   (13.09.17 13:15[106]

А что в вашем понимании "нормальный программист"?
таймер бездействия особенно умиляет.
с системами учета времени реальной работы сотрудников не сталкивались?

А как вам такая аналогия:
Вы приходите в магазин, набираете целую тележку продуктов и на кассе узнаете, что в магазине учет. По заявления господина rrrrrrr ©, это не проблема магазина, это проблема покупателя (пользователя).
Или подойдя к магазину увидеть, что двери закрыты и табличку: "Извините, у нас учет"?

Так какая ситуация вам по душе?
Плюнуть на потраченное время и пойти дальше?
Или изначально пойти в другой магазин?
__
Закрытые двери - блокировка; табличка - уведомление.


macrodens ©   (13.09.17 13:22[107]

kilkennycat ©   (13.09.17 12:53) [105]
Если это просто рядовой программист, то да. Его задача ТЗ реализовать. И тогда все предыдущее обсуждение вообще бред. Так как есть ТЗ, задача от руководства/заказчика. Сказано сделай чтобы Вася знал, что запись уже редактируется Петей и не смог ее отредактировать - делай.
Сказано иначе - делаем иначе.
Все


kilkennycat ©   (13.09.17 13:38[108]


> macrodens ©   (13.09.17 13:15) [106]
> таймер бездействия особенно умиляет.
> с системами учета времени реальной работы сотрудников не
> сталкивались?

кто там говорил про выдергивание из контекста? причем здесь какие-то табельные часы и блокировки?


> Если это просто рядовой программист, то да. Его задача ТЗ
> реализовать.

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


kilkennycat ©   (13.09.17 13:41[109]

а по поводу блокировок и погромистичного варианта - "уральские перльмени" супермаркет пуля"


macrodens ©   (13.09.17 14:13[110]

"уральские перльмени" супермаркет пуля"
поржал


macrodens ©   (13.09.17 14:56[111]

А насчет "да пофиг что надо нажать 36 кнопок одновременно, наймут мутанта" и
"и крайне неверно программисту думать, за счет чего-кого какие издержки спишутся. не в его компетенции. из-за этого и вылазят всякие таймеры-разблокираторы." вы все же утрируете.


Дмитрий   (13.09.17 21:48[112]


> Хочу напомнить, что обычно автоматизация чего-либо подразумевает
> наличие исходных документопотоков. То есть, все нужные задачи
> можно выполнить без автоматизации, вручную. Мне трудно представить,
>  чтобы в реальной жизни один и тот же документ в четыре
> или шесть рук одновременно оформляли несколько человек.


Упомянутая запись представляет собой контроль прохождения изделия по стадия производственного процесса. Некоторые процессы вообще-то идут параллельно, но пока все загнали в одну линию.
Заказчик был абсолютно уверен, что ставить дату исполнения стадии все будут согласно техпроцессу, т.е. в разное время, за исключением некоторых.
Разумеется, когда документ под руками, народ норовит что-то подправить и заполнить не своевременно.
Ибо дела, телефон звонит, сотрудники подходят и просто забыли что-то заполнить.
Все как положено.

Если есть возможность обойтись без блокировок, это предпочтительнее.


Игорь Шевченко ©   (13.09.17 22:18[113]

Дмитрий   (13.09.17 21:48) [112]


> Разумеется, когда документ под руками, народ норовит что-
> то подправить и заполнить не своевременно.
> Ибо дела, телефон звонит, сотрудники подходят и просто забыли
> что-то заполнить.


Бесполезно автоматизировать бардак.


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


Это и надо делать.


Германн ©   (14.09.17 02:16[114]


> Бесполезно автоматизировать бардак.

+100500
Вот тут к совету/мнению ИШ стоит очень внимательно прислушаться.

А по поводу "Разумеется, когда документ под руками, народ норовит что-то подправить и заполнить не своевременно" уже много всего сказано.Разумеется, когда документ под руками, народ норовит что-то подправить и заполнить не своевременно.ли сказанное тебе не помогло, приведи пример, когда не помогло. И обязательно с кодом.


Германн ©   (14.09.17 02:18[115]

P.S Форум  глючит.


Германн ©   (14.09.17 02:20[116]


> .ли сказанное тебе не помогло

Если сказанное тебе не помогло


macrodens ©   (14.09.17 08:18[117]

Дмитрий   (13.09.17 21:48) [112]
Так и я о чем говорю. Если есть возможность делать без блокировок, делаем без них.
Я и не стал бы их использовать, если б не было необходимости.

Бесполезно автоматизировать бардак
Да. Но у нас сейчас как минимум в половине гос.контор бардак и автоматизировать все-равно нужно и приходится. Иногда получается относительно неплохо.

Для некоторых автоматизация это вообще "лишняя работа". Так как: "раньше записывали приход/расход только в журнал (амбарная книга), а теперь еще и в компьютер нужно заносить" - так мне некоторые пользователи 50+ говорят.


версия для печати

Написать ответ

Ваше имя (регистрация  E-mail 







Разрешается использование тегов форматирования текста:
<b>жирный</b> <i>наклонный</i> <u>подчеркнутый</u>,
а для выделения текста программ, используйте <code> ... </code>
и не забывайте закрывать теги! </b></i></u></code> :)


Наверх

  Рейтинг@Mail.ru     Титульная страница Поиск, карта сайта Написать письмо