Сетевая БД

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

0

Сообщение от UBUNTU Да легко: на примере

Речь о том, как правильно это сделать. Ваше приложение (сервер) само должно запомнить ID записи, которую один из клиентов пытается редактировать и не давать другим клиентам открыть форму редактирования той же самой записи.

Если сервер вы заводить не собираетесь, то придётся в базе таблицу отдельную заводить, куда ID записей скидывать, которые сейчас на редактировании. И смотреть в эту таблицу.

0

Usaga, Я согласен это логично и прочие, тогда почему не как в случае с адодб?

0

Сообщение от UBUNTU тогда почему не как в случае с адодб?

Если вы можете использовать этот ADODB и он решает ваши проблемы - используйте.

0

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

0

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

А вот тот вариант, что вы с ADODB показали на мой взгляд вообще противозаконен. Там такое ощущение, что создаётся какая-то транзакция сразу на всё подключение, с эксклюзивной блокировкой. Это было бы не так сильно страшно (хотя всё равно фу), если бы подключение жило не долго. А так, эта транзакция живёт всё время, пока юзер чего-то в UI там делает. А если он вообще уйдёт пить чай?

Долгие транзакции для любой СУБД - преступление. Многие СУБД даже таймауты на это имеют и могут откатывать такие транзакции, если они долго висят.

Поэтому, такие вещи если и нужно делать, то силами собственного кода.

Ну и не факт, что вообще такое нужно реализовывать. Очень и очень часто достаточно просто сравнить версию записи в момент сохранения и всё. В SQL Server для этих целей даже тип колонки есть специальный - timestamp\rowversion. Если значение поля этой записи отличается от того, что было на момент открытия формы (и чтения записи), то пользователю просто можно сказать "Запись изменена другим пользователем. Перезагрузите и отредактируйте снова". И всё.

0

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

0

UBUNTU, LastModifiedUserId вполне распространённое явление. Но это больше для истории, кто последний тут был. А вам достаточно самого факта изменения записи. Плюс, что если один пользователь откроет два клиента и отредактирует одну и ту же запись. Я понимаю, что идиотизм, но ведь возможно. И вариант с "посмотреть на логин последнего редактора" тут не отработает, а простой timestamp - на ура.

0