Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Совместное использование одной таблицы [MSSQL]

Страницы: < 1 2 3 4 5 6 >
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-24 13:28:00) [21]
> ANB (24.11.2006 12:23:29) [89]

Против статустной строки таких возражений нет, кроме дублирование, при щелчке сразу будет нужная информация прямо в месте щелчка. Цвет сменится и не только у данного места, а у всех измененых, а что бы не перегружать запрос, то можно использовать поля типа TimeStamp по терминологии МS SQL сервер, сейчас рекомендуют использовать синоним ROW_VERSION

Anatoly Podgoretsky (2006-11-24 13:25:00) [22]
> ANB (24.11.2006 12:14:25) [85]

set fld=value1 where fld<>value2

Гарантирует, что две одновременные транзакции не смогут привести в не консистентное состояние

clickmaker (2006-11-24 13:11:00) [23]

> Если "виртуальное" поле (вычислимое на сервере-приложений
> в 3х звенке

вычислимое на основании чего?

Sl_RO (2006-11-24 13:09:00) [24]
clickmaker © (24.11.06 12:05) [83]
через доп. поле - это вчерашний век
Если поле в базе - то ДА.
Если "виртуальное" поле (вычислимое на сервере-приложений в 3х звенке)- то НЕТ: синглетон с блокировками (in mem) и клиенты с калк полем

clickmaker (2006-11-24 12:37:00) [25]

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

так я вроде на протяжении всего разговора как раз об этом и говорю...

Jeer (2006-11-24 12:36:00) [26]

> clickmaker © (24.11.06 12:26) [90]

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

Транзакции совершенно необходимы в конкурирующих (параллельных) обращениях, когда логической единицей служат наборы операций (SELECT, INSERT, UPDATE,DELETE).

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

clickmaker (2006-11-24 12:26:00) [27]
Ну хорошо, если все согласились, что дело только в терминологии, и данное решение имеет место быть, то я еще раз прошу уважаемого MsGuns объяснить мне
1) в чем мое непонимание технологии "клиент-сервер"
2) почему я должен обратить свое внимание именно на понятие "транзакции"
3) почему техника, которую я использую - "из песка и алебастра", и какие есть альтернативы. Именно для данной задачи

Обвинения нужно аргументировать

ANB (2006-11-24 12:23:00) [28]

> так и по клику и сообщений не надо выдавать, просто перерисовать

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

Anatoly Podgoretsky (2006-11-24 12:19:00) [29]
> clickmaker (24.11.2006 12:07:24) [84]

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

Anatoly Podgoretsky (2006-11-24 12:17:00) [30]
> clickmaker (24.11.2006 12:05:23) [83]

На сервере ничего не надо делать, на сервере всегда актуальное состояние.
Если сервер начинает что то рассылать, то он превращается в клиента. Это по определению клиент/сервер.

Anatoly Podgoretsky (2006-11-24 12:16:00) [31]
> ANB (24.11.2006 12:00:21) [81]

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

ANB (2006-11-24 12:14:00) [32]

> Сам же намекнул, что через доп. поле - это вчерашний век.
>
> А как тогда? Статус-то места где хранить, если не в поле?
>

Блокировка через поле - вчерашний век. А резервирование через него и делается. Нужно только в update обязательно вписать условие, проверяющее, что долей секунды раньше место не захапал другой оператор.
Короче - Jeer все объяснил.
Кистате, в элементарном случае с 3-мя статусами Свободно/Оформляется/Продано можно и на блокировках все замутить - только проблема с определением - ктож хапнул то ? Хотя конкретному кассиру обычно это и не нужно.

clickmaker (2006-11-24 12:07:00) [33]

> [82] Anatoly Podgoretsky © (24.11.06 12:04)
> > clickmaker (24.11.2006 11:30:19) [79]
>
> Резервирование и они должны быть отображены другим цветом,
> поскольку и них нет статуса Свободные/Проданые, но почему
> через блокировку это надо делать не пойму, надо сменить
> для данного конкретного случая (места в в зале) статус на
> Зарезервировано и все

Господи, так а я об чем?
Ну неправильно я сказал "блокировка", но поправился уже ведь

clickmaker (2006-11-24 12:05:00) [34]

> Время от времени рефрешить экран

это клиентское решение. Интересует, как на сервере это оформить. Сам же намекнул, что через доп. поле - это вчерашний век.
А как тогда? Статус-то места где хранить, если не в поле?

Anatoly Podgoretsky (2006-11-24 12:04:00) [35]
> clickmaker (24.11.2006 11:30:19) [79]

Резервирование и они должны быть отображены другим цветом, поскольку и них нет статуса Свободные/Проданые, но почему через блокировку это надо делать не пойму, надо сменить для данного конкретного случая (места в в зале) статус на Зарезервировано и все.
Узнать, тут просто пока не сделаешь запрос к серверу то не узнаешь, на экране показывается некоторое прошлое. Делают или кнопкой обновить, или имеют специальное окно для выбора со схемой распределения мест в зале, подойди к любой кассе и посмотри как это делают вручную. У кассира лежит бумажка со схемой мест в зале. Пока один кассир, то это не вызывает проблем, если больше одного, то это решают или распределением по диапазону или с помощью интеркома следующим образом - Резервирую место такое то, место такое то продано, место такое возвращено из резерва и все операторы отмечают это на бумажки.

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

ANB (2006-11-24 12:00:00) [36]

> Приходится администратору лезть на сервер и снимать блокировку.

Достаточно убить мертвую сессию.

> Вопрос: как мне узнать на этот период времени, что именно
> ЭТИ 3 места заняты, и мне даже не стоит щелкать по ним мышкой,
> чтобы отложить в другой заказ?

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

Jeer (2006-11-24 11:44:00) [37]
Все зависит от того, что считать под блокировкой.

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

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

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

Пример.
Менеджер работает с клиентом (заказом клиента) и "ведет" его в течение м.б. нескольких дней, месяцев.
В этом случае должно выполняться резервирование (закрепление) клиента за конкретным менеджером. Это можно назвать блокировкой клиента для других менеджеров. Разумеется, здесь нет никакой транзакции в смысле СУБД, а может быть только откат (сторнирование) операции тем же менеджером или главным менеджером.

Как реально выполняется резервирование ?
У клиента X есть метка (поле IDM) - ID менеджера.
Например ID=0 - клиент ни за кем не закреплен и далее по номерам менеджеров.
Менеджер, обрадовавшись клиенту спешит закрепить его за собой.
Открывает форму с клиентами и ищет такового.
В зависимости от реализации процесса могут быть показаны все клиенты или только свободные клиенты.
Предположим реализация такова, что показаны все клиенты и не визуализированы признаки закрепленности.
Менеджер выбирает клиента X и нажимает кнопочку "Закрепить".
Приложение выполняет операцию с SQL командой:
UPDATE CLIENTS SET IDM = 1 WHERE ( ID = X ) AND ( IDM = 0 );

В данном случае, если клиент не занят, то происходит перезапись IDM с 0 на 1, если нет - то и не перезапишет.
По DBErrors приложение извещает менеджера о неудаче, т.е. о занятости клиента.

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

clickmaker (2006-11-24 11:30:00) [38]

> [77] Anatoly Podgoretsky © (24.11.06 11:24)

так. Рассмотрим пример. Я кассир. продаю билеты на концерт. У меня на мониторе схема зала с местами. Свободные - белые, проданные черные. Другой кассир выделил, допустим, 3 места и оформляет заказ. Это может занять некоторое время. Это разве не резервирование с его стороны?

Вопрос: как мне узнать на этот период времени, что именно ЭТИ 3 места заняты, и мне даже не стоит щелкать по ним мышкой, чтобы отложить в другой заказ?

Anatoly Podgoretsky (2006-11-24 11:26:00) [39]
> ANB (24.11.2006 10:54:16) [76]

А если клиентская программа навернется - блокировка снимется сама.

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

Anatoly Podgoretsky (2006-11-24 11:24:00) [40]
> clickmaker (24.11.2006 10:05:15) [75]

Как раз ты говоришь о блокировке, а не о резервировании. Никто другой не может редактировать и даже читать (термин использовать). А резервирование немного другое, например у на складе есть 10 единиц товара, количество товара не может переходить в минус.
Например первый оператор резервирует за собой 7 единиц, то другие могут получть только 3 и не более, по окончанию операции делается или проводка списания, или возрат резерва.
Оператор должен знать кто зарезервировал и когда.
Операция возврата штатная и может выполняться любым допущеным человеком, в отличии от блокировок она не мешает работе других пользователей, поскольку ничего ни физически, ни логически не блокируется.

Страницы: < 1 2 3 4 5 6 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »