forum.clarionlife.net

Как Вы вообще это делаете?

kreator писал(а): ↑16 Октябрь 2020, 12:39 Как Вы вообще это делаете?

О чем вопрос?

Admin писал(а): ↑16 Октябрь 2020, 13:28

kreator писал(а): ↑16 Октябрь 2020, 12:39 Как Вы вообще это делаете?

О чем вопрос?

У finsoftrz спросил. А он ушёл в тень . Есть проблема узнать кто редактирует запись. Даже на концептуальном уровне.

Я тоже не телепат.
На концептуальном уровне это служебная табличка. Когда пользователь открывает объект на редактирование, туда делается запись (тип объекта, идентификатор, пользователь). Когда заканчивает редактировать, запись удаляется. При входе в программу все записи пользователя зачищаются на случай аварийного выхода. Ну и другой пользователь с админскими правами может принудительно почистить аварийные записи в диалоге "Редактируемы объекты". На практике каких-либо проблем не возникало, это все в продакшене работает больше 15 лет. Случаев аварийного отвала очень мало, и прозрачно, что надо делать.

finsoftrz писал(а): ↑16 Октябрь 2020, 17:58 На практике каких-либо проблем не возникало, это все в продакшене работает больше 15 лет. Случаев аварийного отвала очень мало, и прозрачно, что надо делать.

Это Вы как всегда привираете. Чтобы "захваченную" запись отпустить нужно этому же пользователю вновь зайти или админу поработать. Специфичное решение.

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

эта конструкция только с ISAM работает, с клиентом на SQL и на удаленном сервере такое не пройдет

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

Если sql, то тут надо смотреть, какой сервер конкретно. Например, у postgreSQL есть так называемые пользовательские блокировки, которые автоматически снимаются при потере соединения.

В целом, с sql все сложнее в плане интерактивной работы. Взять тот же вопрос с верификацией ввода данных. Делать на клиенте, это юзабельно с точки зрения пользователя, но слишком частые запросы. На сервере, то пользователь вводит-вводит, а ему фига потом прилетает. Хорошо, если что-то вменяемое, а то и абракадабра непонятная какая-нибудь. Помню, Андрей Мялин в mav специальную кнопочку в окне с сообщением делал, скопируйте в буфер обмена и отправьте разработчику. Забавно выглядело.

В action zen (btrieve) одной из последних разработок был сервер отчетов. То есть предлагается вводить данные в основной базе по записям. Автоматически изменения реплицируются во вторую базу данных сервера отчетов. С сервером отчетов уже работают через sql запросы. Типа соединяем лучшее из двух миров в одном решении. Насколько я читал, в крупных конторах разделение базы на оперативную и для отчетов часто применяемое решение, безотносительно, по какой схеме осуществляется доступ к базе данных.

gopstop2007 писал(а): ↑17 Октябрь 2020, 8:26 эта конструкция только с ISAM работает, с клиентом на SQL и на удаленном сервере такое не пройдет

Подход finsoftrz "работает" везде. Просто он концептуально неправильный. А админы не обращаются, потому что либо пользователей мало либо научились выкручиваться.
Мне вот чего непонятно. Есть более-менее нормальные варианты. В т.ч. подход SV. Накой городить свой огород, который изначально в нерабочем состоянии?
Я спросил, думал - вдруг что-то нашёл интересное. А здесь опять параллельная реальность.

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

То, что предлагается стандартно в кларионе (watch/hold, видимо) нормально работает в определенных условиях. Но по мере усложнения логики приложения удобнее оперировать на уровне бизнес объектов, а не блокировок отдельных записей.

finsoftrz писал(а): ↑17 Октябрь 2020, 13:52 В моем случае (встроенные базы данных) это работает хорошо. Более надежных критериев оценки, чем многолетняя стабильная работа в продакшене, я не знаю.

Как это может работать хорошо? Привожу пример. Манагер редактирует счёт. У него виснет комп или с сетью проблемы. Он чертыхается, бросает всё и идёт домой, в смысле культурно отдыхать, конец рабочего дня. Звонит клиент и говорит "Дайте счёт, сейчас оплачу. Не будет счёта в течении получаса, пошли в жопу". И чего? Манагер уже недоступен, культурно отдыхает. Админ вообще не в штате, тоже культурно отдыхает. Часа два все в мыле, кое-как запись разблокировали. Но уже поздно, были посланы.
И SQL не причём. Здесь концептуальная проблема.

kreator писал(а): ↑17 Октябрь 2020, 15:45 И SQL не причём. Здесь концептуальная проблема.

c SQL все еще хуже, в моем случае с Mysql.

Элементарно решается сбросом сеанса пользователя в несколько кликов мышкой. Главное, что понятно, кто документ редактирует. Опять таки, документ можно открыть на просмотр и там доступны все функции, кроме редактирования. Например, распечатать или сохранить в excel. Наконец, документ можно просто скопировать и делать в копии что угодно. Я не говорю уж о том, что подобная ситуация придумана и в реальной жизни маловероятна.

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

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

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

finsoftrz писал(а): ↑17 Октябрь 2020, 16:13 И уж точно, не надо засорять данный топик углублением в специфические вопросы

Вот это было смешно.

Не знал, в каком месте ввернуть, чтобы поставить точку. Неохота лясы по очевидным вопросам точить. Ввернул в первом попавшемся.