![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Совместное использование одной таблицы [MSSQL]
DeadMeat © (2006-11-20 16:57:00)Здравствуйте.
Я в базах новичек, поэтому сильно не бейте (хотя бы не ногами).
Есть:
СУБД Microsoft SQL 2000 (SP3)
ADO (компоненты ADOConnection и ADODataSet)
EhLib (компоненты MemTableEh и DBGridEh)
Таблица (просто список людей)
Несколько пользователей (работники)
Надо:
При совместной работе с одной таблицей двух и более пользователей разруливать ситуацию с обновлением информации.
Понимаю, что сказал бред. Попробую пояснить.
Допустим пользователь ЮЗЕР1 выбрал первую запись для редактирования (первая - это образно, первая сверху). Отредактировал и сохранил обратно в базу (MemTableEh.Edit, MemTableEh.Post, MemTableEh.ApplyUpdates(0)). Если после этого пользователь ЮЗЕР2 решит отредактировать эту же запись, то выскочит ошибка "Не удается найти строку для обновления.......". Погуглив выяснилось, что проблема в том, что после редактирования найти эту запись ЮЗЕР2 уже не может, т.к. критерии поиска уже другие. Соответственно
введя первичный ключ и добавив в AfterOpen задание параметра Update Criteria значением adCriteriaKey проблема решается. Но лишь проблема появления ошибки. Т.е. получается, что ЮЗЕР2 не видя то, что записал в базу ЮЗЕР1 запишет туда что-нить свое. А вот хотелось бы отобразить изменения, которые сделал ЮЗЕР1 для всех остальных пользователей. Вводить дополнительно сетевую часть (передавать всем броадкастом информацию об обновлениях) не очень хочется. Каждый раз делать Requery перед редактированием любой записи тоже. Может есть способ еще? Как определить, что "вот эту"запись изменили, и что "вот эту"запись надо обновить? Пробовал проверять RecordStatus на rsModified - не помогло.
ЗЫ. Вполне вероятно, что гдето написал бред, но я только начал эту область осваивать.
ЗЗЫЫ. Пишу в BDS2006.
Anatoly Podgoretsky (2006-11-26 19:50:00) [1]> clickmaker (26.11.2006 18:36:54) [114]
Конечно, один перевод термина потоки чего стоит.
Palladin (2006-11-26 19:18:00) [2]
> [112] clickmaker ©
только не объекта, а сущности :), это единственный реальный способ отслеживания ее состояния на распределенных системах и системах без поддержки постоянного соединения до сервера, самый главный его плюс - он не зависит от особенностей того или иного хранилища данных...
> [103] Anatoly Podgoretsky ©
сервер приложений ничего не решает, состояния сущностей должны быть устойчивыми, а не зависеть от времени выполнения сервера приложений, на сервер должен ложиться лишь их мониторинг, в случае, скажем давно уже несуществующей сессии клиента (мышка провод перегрызла), так же необходимо будет и обновить состояние помеченное этой бывшей сессией...
clickmaker (2006-11-26 18:36:00) [3]
> [113] Anatoly Podgoretsky © (26.11.06 18:28)
> > clickmaker (26.11.2006 18:13:52) [112]
>
> А ты чего то другого ожидал от публичного форума?
Я начинаю понимать, почему америкосы обходят нас по части ПО. Английский язык допускает гораздо меньше неоднозначностей в терминах, и они быстрее договариваются... ))
Anatoly Podgoretsky (2006-11-26 18:28:00) [4]> clickmaker (26.11.2006 18:13:52) [112]
А ты чего то другого ожидал от публичного форума?
clickmaker (2006-11-26 18:13:00) [5]
> ак настойчиво навязываемый Вами пример "двух кассиров",
> где будто бы надо чего-то разруливать и кого-то о чем-то
> оповещать, как раз и не нуждается ни в каких блокировках
Там где два, там может быть и двадцать два. Причем тут количество? Важен принцип. Я предлагал всего лишь использовать некое поле для обозначения статуса ОБЪЕКТА, именно объекта, а не записи. Зарезервирован, свободен, продан и т.д. - набор состояний зависит от предметной области. Я сам противник использования напропалую каких-либо специфичных для серверов БД фич, о чем, кстати, здесь упоминал.
Вы же налетели как коршун, даже не попытавшись разобраться, о чем речь. Вот что обидно, а не "честь мундира"....
Anatoly Podgoretsky (2006-11-26 17:06:00) [6]> clickmaker (26.11.2006 13:21:50) [110]
Если бы ты придумал самопальный термин это одно, но термин который весьма конкретен для баз данных совсем другое.
clickmaker (2006-11-26 13:21:00) [7]
> [109] MsGuns © (25.11.06 23:12)
Ну хорошо. Вот мои первые посты
>Т.е. либо есть некий сервис, который оповещает остальных, что некто Вася >поменял запись 1. После 2 варианта. Либо переоткрытие датасета, либо >вообще не используется грид, а например ListView. Тогда можно >индивидуально управлять записями по ID.
>Еще вариант, если записей не слишком много, и жесткий риалтайм не >нужен, то по таймеру обновлять табличку на клиенте.
>Для особо критичных данных иногда применяют следующее. Грид >редактировать запрещают вообще. Только специальной формой. При >открытии формы запись блокируется. Все остальные после этого получают >либо отлуп, либо предложение открыть инфу для чтения. Эта идея с успехом >используется в офисных приложениях (ворд, эксель).
>Форма закрылась - блокировку снимаешь
Здесь я предлагал использовать технологию, которую Анатолий потом назвал "резервирование". Согласен, я неверно использовал термин, что видимо и вызвало у вас такую бурную реакцию.
Но не подумали же всерьез, что я предлагаю на открытие формы блокировать запись средствами сиквела или (что еще хуже) стартовать транзакцию, а при закрытии накатывать или откатывать?
Я может и не совсем заслуженно ношу значок, но я не настолько туп, знаете...
MsGuns (2006-11-25 23:12:00) [8]>clickmaker © (24.11.06 17:55) [108]
>из какого моего поста это следует?
Да практически с первого Вашего вступительного поста Вы начинаете развивать технологию блокировок, которые есть фикция, "муляж" в клиент -серверных платформах.
Так настойчиво навязываемый Вами пример "двух кассиров", где будто бы надо чего-то разруливать и кого-то о чем-то оповещать, как раз и не нуждается ни в каких блокировках, а если такие используются разработчиком (но никак не сервером), то это уже результат не слишком высокой его (разработчика) квалификации и недостатка опыта.
Вам целым кагалом пытались объяснить Ваши заблуждения, советуя и литературу, и присмотреться к хорошо зарекомендовавшим себя системам, но Вы почему-то из всех выделлил MsGuns инастойчиво пытаетесь призвать его "к ответу".
Мне это не нужно. Если Вам в этой ветке важнее всего сохранить "честь мундира", а не поучиться у тех, кто элементпрно грамотнее или опытнее Вас в этом вопросе, то я ошибся, встряв в нее. Поэтому в третий и последний раз приношу свои извинения и прощаюсь.
clickmaker (2006-11-24 17:55:00) [9]
> [106] msguns © (24.11.06 17:12)
> потому что нет понимания "транзакций"
из какого моего поста это следует?
ANB (2006-11-24 17:31:00) [10]
> как реальных сущностей (полей БД) - а это уже по сути "локалка"
> со всеми вытекающими
Во - вы тоже за использование по возможности родных блокировок ?
msguns (2006-11-24 17:12:00) [11]>clickmaker © (24.11.06 12:26) [90]
>Ну хорошо, если все согласились, что дело только в терминологии, и данное решение имеет место быть, то я еще раз прошу уважаемого MsGuns объяснить мне
Дался Вам этот "Ганз" ;))
>1) в чем мое непонимание технологии "клиент-сервер"
потому что нет понимания "транзакций"
>2) почему я должен обратить свое внимание именно на понятие "транзакции"
Потому что это "сердце" любого сиквель-сервера
3) почему техника, которую я использую - "из песка и алебастра", и какие есть альтернативы. Именно для данной задачи
Дело не в задаче, а в подходе. Ваш подход основан на фиксации виртуальных событий ("занято", "свободно"..) как реальных сущностей (полей БД) - а это уже по сути "локалка" со всеми вытекающими, о чем тут уже горы наговорено. Этого делать нельзя? ибо Вы пытаетесь проблемы пассажиров и водителей повесить на автодорожников - из этого ничего хорошего не получится, разве что в каком-нибудь Мухосраснске с единственной дорогой, десятью дворами с имеющимися в наличии тремя мотоциклами и шестью велосипедами в общей сложности.
Обвинения нужно аргументировать
Я Вам приводил примеры, какие еще Вам нужны аргументы ? Или Вы думаете? что с точки зрения сиквель-сервера "Опербанк" и "Два кассира" есть? как говорят в Одессе? "две большие разницы" ?
ЗЫ. Еще раз повторяю, что если в моем "наезде" Вас больше всего покоробил акцент на значок, то я приношу извинения и забираю свои слова назад? этого будет достаточно для того, чтобы Вы перестали обмывать мои косточки ? ;)
Anatoly Podgoretsky (2006-11-24 14:45:00) [12]> Jeer (24.11.2006 14:08:44) [104]
Дык основы :-)
Anatoly Podgoretsky (2006-11-24 14:08:00) [13]> SlymRO (24.11.2006 13:43:40) [100]
Естественно сервер приложений может вести свои списки состояний.
Jeer (2006-11-24 14:08:00) [14]
> Anatoly Podgoretsky © (24.11.06 14:07) [102]
Я о том же.
Еще лучше - когда трое о том же:)
Anatoly Podgoretsky (2006-11-24 14:07:00) [15]> Jeer (24.11.2006 13:36:39) [99]
Атомарной, отдельная операция атомарно, поэтому явная транзакция не нужна.
Пакет не атомарен, поэтому явно.
clickmaker (2006-11-24 14:04:00) [16]
> [100] SlymRO (24.11.06 13:43)
> clickmaker © (24.11.06 13:11) [94]
> вычислимое на основании чего?
> На основании таблицы блокировок (ТБ) на сервере приложений
> (СП):
мы говорим про клиент-сервер. У нас нету сервера приложений
SlymRO (2006-11-24 13:43:00) [17]clickmaker © (24.11.06 13:11) [94]
вычислимое на основании чего?
На основании таблицы блокировок (ТБ) на сервере приложений (СП):
Клиент запрашивает данные у СП, СП к возвращаемым данным прицепляет доп. поле с вылукаплеными (о как сказал) значениями из ТБ. ТБ обязательно в памяти, но можно и на диск сбрасывать, но тогда при запуске сервера обязательно ее очищать.
Jeer (2006-11-24 13:36:00) [18]
> Anatoly Podgoretsky © (24.11.06 13:30) [97]
> Транзакция все равно есть, только неявная,
Это-то понятно, но мы пока не лезем в потроха движка СУБД.
Атомарной должна быть любая операция, в том числе и SELECT.
Надо будет - залезем:)
Anatoly Podgoretsky (2006-11-24 13:31:00) [19]> Sl_RO (24.11.2006 13:09:33) [93]
Если трехзвенка то много вопросов решается, в том числе и состоянием.
Anatoly Podgoretsky (2006-11-24 13:30:00) [20]> Jeer (24.11.2006 12:36:31) [91]
Транзакция все равно есть, только неявная, даже для SELECT
но явная нужна именно только пачки операций.