Продажа билетов несколькими кассирами

← →
alabama01 (2006-09-26 07:09) [0]

Здравствуйте.
Есть программа для продажи билетов в транспортные средства, с соответсвующей БД. При продаже билета на форме кассира обновляется combobox со списком свободных мест и автоматически подставляется первое свободное место. (сделано для скорости). При работе нескольких кассиров, у них у всех происходит то же самое. Поэтому приходится проверять не продал ли кто билет на это место, а если продал, то выводить предупреждение, чтобы выбирали другое место. Это очень неудобно. Обновление combobox"ов у всех кассиров происходит при оформлении чека любым из кассиров Вопрос: как лучше организовать раздачу свободных мест при продаже на один и тот же рейс несколькими кассирами без малейшей возможности продажи двух и более билетов на одно место?

← →
Бугага © (2006-09-26 07:15) [1]

Первый выбирает место, лочит, пытается зарегистрировать билет. Пока он его регистрирует, место залочено. Регистрация успешна? -> место ушло, не успешна -> место разлочено

← →
vodvorezlaya (2006-09-26 08:22) [2]

1.Сделать столбик базы данных уникальным, и ловить исключение.

2.Сделать поле ключевым, и ловить исключение либо делать поиск FindKey;

← →
ЮЮ © (2006-09-26 09:02) [3]

> vodvorezlaya (26.09.06 08:22) [2]

Уже книжек начитался, гляжу :) И в каких только таких "терминов" нахватался? :)

← →
evvcom © (2006-09-26 09:05) [4]

> [3] ЮЮ © (26.09.06 09:02)

Ну дай ему орлом себя почувствовать... :-o)

← →
atruhin © (2006-09-26 09:46) [5]

С MSSQL не работал, а в FB можно при выборе места делать холостой апдейт, после чего данная запись будет заблокированна, для второго кассира, простым перебором ищем незаблокированные записи, + event на блокировку для синхронизации конецформыначалоформыcombobox"ов.
При закрытии пргораммы, обрыве коннекта, транзакция через некоторое время (настраивается) откатывается и запись разблокируется.
Думаю в MSSQL есть что то подобное.

← →
Бугага © (2006-09-26 09:59) [6]

> И в каких только таких "терминов" нахватался? :)

Архангельский? :)

← →
alabama01 (2006-09-26 10:21) [7]

> Бугага © (26.09.06 07:15) [1]

Пока так и есть. Если запись залочена, то второму кассиру выводим сообщение, и он выбирает другое место. Вопрос когда лочить.

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

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

← →
ЮЮ © (2006-09-26 10:29) [8]

Я бы разделил операции на
"забронировать для оформления" N мест
"выбрать N мест"
"оформление билетов на выбранные места"

Ибо, сначала покупатель говорит : Мне 3 билета на рейс ХХХ

Затем отдает документы, из когорых становится ясно, что нужен 1 бзрослый и 2 детских места, выясняется в каком вагоне(классе, ряду) нужно место

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

Первая операция позволяет сразу сказать есть нужное количество мест или нет. Выполняется без блокировки. Может сказать "Извините", если мест "на лету" стало меньше. Не требует много времени кассира

Вторая выполняется в порядке поступления блокировок. Тоже не требует много времени у кассира. Но надо разлуривать "уснувшего" кассира.

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

З.Ы. Сам таких систем не писал. Как работают реально действующие - не представляю. Так что, извиняйте :)

← →
Бугага © (2006-09-26 10:29) [9]

> Вопрос когда лочить

Лочим при начале оформления.

Насчет
> если этот билет последний и второй кассир хочет его продать,
> а первый пошел покурить?

административные меры

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

не понял. конец рабочего дня дает знать...

← →
evvcom © (2006-09-26 10:30) [10]

> [7] alabama01 (26.09.06 10:21)

Имеется оптимистический вариант блокирования и пессимистический. Поскольку

> у нас свободные билеты хранятся в одном числе по битам

тебе оптимизм не подойдет. А пессимистический делается так:
select ... from ... where ... for update
Вызываешь это, когда кассир уже покурил и нажал кнопку "Выдать билет". Следом за этим в программном блоке Delphi делаешь проверку, а не изменился ли уже нужный тебе бит, если не изменился, то меняешь и тут же update с коммитом, если изменился - rollback и соответствующее сообщение долго курящему кассиру выдаешь. И пофиг, какой кассир и как долго ходил курить, другим он не помешает.

← →
ЮЮ © (2006-09-26 10:31) [11]

свободные билеты хранятся в одном числе по битам

Это что за средство передвижения такое: маловместимое и с большой конкуренцией на ресурсы? :)

← →
Бугага © (2006-09-26 10:32) [12]

понял про хранение билетов... а зачем такой гемор?

:)
> Вызываешь это, когда кассир уже покурил и нажал кнопку "Выдать
> билет".

т.е. один кассир занял это место, второй тоже, а там кто успеет?

← →
Ega23 © (2006-09-26 10:35) [13]

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

← →
evvcom © (2006-09-26 10:40) [14]

> [12] Бугага © (26.09.06 10:32)
> т.е. один кассир занял это место, второй тоже, а там кто
> успеет?

Занял - это когда смог обновить запись в базе и распечатать билет. Все остальное - это только мысли занять. Я расписывал классику обновления записей, где вероятность ошибки должна быть сведена к 0. Если же интересует вопрос удобства работы кассиры, это уже другой вопрос. Например, [8] вроде неплохая идея (я тоже не писал такой задачи). А успеть на одно место всегда может только один. Ну прям горец получается :)

← →
Бугага © (2006-09-26 10:47) [15]

в том то и фишка подобных систем что классика здесь вряд ли подойдет.
[8] пропустил, мне тоже понравилось

← →
Виталий Панасенко (2006-09-26 11:26) [16]

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

← →
atruhin © (2006-09-26 11:26) [17]

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

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

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

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

← →
dr Gonzo © (2006-09-26 11:31) [18]

Сам механизм блокировки реализовать как запись ID билета(номера) в спец-ю таблицу или что хуже простановка атрибута у записи.

Собственно блокировать(пытаться заблокировать) на время оформления по выходу из ComboBox"а. Или если это множественный выбор, то нужно сделать контейнер (типа TListBox"а) для "набивки" заказа билетами из другого списка и делать блокировку при добавлении каждого билета в этот контейнер.

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

Все делается за счет 1 ступени блокировки.

Делать сообщения о создании/снятии блокировки. Так же я предложу сделать сообщения более информативными - не просто что то поменялось, а поменялось то то и то то (в идеале снята/поставлена блокировка, ID объекта и т.д. - тогда не нужно будет все время делать Refresh из базы).

Сразу скажу какие минусы у этого способа. Тетя Маша выбрала для заявки 1 - NN билетов, клиент отказался, она ушла пить чай/курить/cпать при этом не закрыв заказ - заказ висит заблокированный, другие пользрователи не могут ничего с этими билетами делать.

← →
evvcom © (2006-09-26 11:33) [19]

> [15] Бугага © (26.09.06 10:47)
> в том то и фишка подобных систем что классика здесь вряд
> ли подойдет

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

> [8] пропустил, мне тоже понравилось

я не говорю, что понравилось, просто как вариант, далекий от идеального

← →
Desdechado © (2006-09-26 11:45) [20]

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

ЗЫ кстати, как в таком случае разруливается ситуация с разным количеством мест в разных транспортных средствах?

← →
Val © (2006-09-26 11:47) [21]

>[10] evvcom © (26.09.06 10:30)
мне кажется - все-таки в данном случае воспользоваться оптимистической блокировкой. чем мешает это поле, поясните?
пока первый кассир курит - место считается свободным, поскольку транзакция не завершена. при оптимистическом подходе у второго кассира получится вставить запись без проблем. первый вернется из курилки попробует закончить операцию - получит отказ и откат, поскольку запись с таким местом в базе уже будет.
for update - разве есть в MSSQL?

← →
evvcom © (2006-09-26 11:51) [22]

> [20] Desdechado © (26.09.06 11:45)

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

← →
evvcom © (2006-09-26 11:56) [23]

> [21] Val © (26.09.06 11:47)
Оптимистическая:
update tab set mesta = :mesta where id = :id and mesta = :old_mesta
Если кассиров много будет выдавать билеты на автобус/поезд id, то с битовым подходом занятости мест mesta очень часто не будут совпадать с :old_mesta. Решать, конечно, барину.

← →
Desdechado © (2006-09-26 12:03) [24]

> А реляционная алгебра... а что из нее здесь нужно? Для количества можно
> использовать, что угодно, поддерживающее достаточную длину
Главное преимущество реляционного подхода - это возможность складировать в столбик то, что часто просится складироваться в отдельных полях строки (или в битах чиста, или в блобе).
Т.е. проданные билеты просто появляются в таблице отдельными строками, а в справочнике транспортного средства хранится его емкость. Непроданные записывать смысла нет. Количество свободных легко считается, их номера тоже легко (про занятые уже не говорю).

← →
Val © (2006-09-26 12:16) [25]

>[23] evvcom © (26.09.06 11:56)
можно использовать and mesta = :old_mesta не напрямую, а и через функцию, которая возвращает признак что данное место свободно.

← →
Виталий Панасенко (2006-09-26 12:37) [26]

А нельзя ли кассирам дать диапазон №№ ?

← →
evvcom © (2006-09-26 12:41) [27]

> [24] Desdechado © (26.09.06 12:03)

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

> [25] Val © (26.09.06 12:16)

Да, так согласен. Кстати,

> [21] Val © (26.09.06 11:47)
> for update - разве есть в MSSQL?

Есть, конечно.

← →
Val © (2006-09-26 12:46) [28]

>[27] evvcom © (26.09.06 12:41)
> Есть, конечно.

спасибо.

← →
clickmaker © (2006-09-26 14:57) [29]

> у нас свободные билеты хранятся в одном числе по битам

32, ну максимум 64 места? Что за транспорт?

← →
Desdechado © (2006-09-26 15:16) [30]

в продолжение Desdechado © (26.09.06 12:03) [24]
если нужно будет к проданному билету (месту) прилепить еще что (например, льготу или фамилию), то это как раз очень удобно делается таким подходом
а вот к биту прилепить только перректально
кстати, если транспортное средство не со сквозной нумерацией мест (например, в поезде вагон-место), то биты идут лесом, т.к. кол-во вагонов произвольное, да и их номера не всегда подряд

← →
ANB © (2006-09-26 15:27) [31]

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

дамс. видимо на одной автостанции подобная прога уже стоит. Продали мне билет на место номер 7. залезаю в автобус - а места с таким номером нету :) Пришлось согнать нафиг кондуктора и ехать на ее месте.

← →
Sergey13 © (2006-09-26 15:28) [32]

> [31] ANB © (26.09.06 15:27)

7 - счастливый номер. На нем водитель сидит. 8-)

← →
alabama01 (2006-09-27 02:28) [33]

> ЮЮ © (26.09.06 10:29) [8]

Идея неплохая. Надо обмозговать.

> evvcom © (26.09.06 10:30) [10]

> тебе оптимизм не подойдет. А пессимистический делается так:
>
> select ... from ... where ... for update
> Вызываешь это, когда кассир уже покурил и нажал кнопку "Выдать
> билет". Следом за этим в программном блоке Delphi делаешь
> проверку, а не изменился ли уже нужный тебе бит, если не
> изменился, то меняешь и тут же update с коммитом, если изменился
> - rollback и соответствующее сообщение долго курящему кассиру
> выдаешь. И пофиг, какой кассир и как долго ходил курить,
> другим он не помешает.

Так и так сейчас делается. И, в данном случае, не имеет значения "уснул" ли кассир или он колотит билеты один за другим!

> ЮЮ © (26.09.06 10:31) [11]
> свободные билеты хранятся в одном числе по битам
>
> Это что за средство передвижения такое: маловместимое и
> с большой конкуренцией на ресурсы? :)

Автобусы пригородных сообщений, максимум 60 мест.

> Бугага © (26.09.06 10:32) [12]
> понял про хранение билетов... а зачем такой гемор?

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

> Ega23 © (26.09.06 10:35) [13]
> А я бы комбики обновлял не принудительно, а только тогда,
> когда данный кассир пытается что-то продать

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

> Виталий Панасенко (26.09.06 11:26) [16]
> А у кассира есть возможность менять номер места ? Или всегда
> только первый из комбобокса берется ?

Конечно. Кассир может выбрать любое место из всего диапазона свободных.

> atruhin © (26.09.06 11:26) [17]
> > что делать если этот билет последний и второй кассир хочет
> его продать, а первый пошел покурить?
>
> Во первых административные меры, во вторых для забывчивых,
> таймер на окно выписки билета, при неактивности кассира,
> закрывается запись разблокируется.

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

> dr Gonzo © (26.09.06 11:31) [18]

Про механизм блокировки. Можно и так, конечно. Сейчас у нас просто переписывается число содержащее список свободных мест.
Про сообщения не понял. Сообщения кому? Кассиру?
Про тетю Машу, думается разблокировка по таймеру должна помочь.

> Desdechado © (26.09.06 11:45) [20]
> хранение в битах - глупость, которая не дает нормально развернуться
> методам реляционной алгебры
> ведь БД - это все-таки реляционный механизм

Думаю, если этого достаточно, почему бы и нет?

>
> ЗЫ кстати, как в таком случае разруливается ситуация с разным
> количеством мест в разных транспортных средствах?

Заполнением нулями соответствующих битов.

> evvcom © (26.09.06 11:56) [23]
> > [21] Val © (26.09.06 11:47)
> Оптимистическая:
> update tab set mesta = :mesta where id = :id and mesta =
> :old_mesta
>
> Если кассиров много будет выдавать билеты на автобус/поезд
> id, то с битовым подходом занятости мест mesta очень часто
> не будут совпадать с :old_mesta. Решать, конечно, барину.
>

> Обновление combobox"ов у всех кассиров происходит при оформлении
> чека любым из кассиров

> Виталий Панасенко (26.09.06 12:37) [26]
> А нельзя ли кассирам дать диапазон №№ ?

Нельзя. Все продают всё.

> Desdechado © (26.09.06 12:03) [24]

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

> Desdechado © (26.09.06 15:16) [30]

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

> ANB © (26.09.06 15:27) [31]
>
> > кстати, если транспортное средство не со сквозной нумерацией
>
> > мест (например, в поезде вагон-место), то биты идут лесом,
>
> > т.к. кол-во вагонов произвольное, да и их номера не всегда
>
> > подряд
>
> дамс. видимо на одной автостанции подобная прога уже стоит.
> Продали мне билет на место номер 7. залезаю в автобус -
> а места с таким номером нету :) Пришлось согнать нафиг
> кондуктора и ехать на ее месте.

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

← →
atruhin © (2006-09-27 05:48) [34]

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

← →
alabama01 (2006-09-27 07:42) [35]

> atruhin © (27.09.06 05:48) [34]

К сожалению, выбор места требует заказчик. Если бы автоматом, проблем бы не было.

← →
Sergey13 © (2006-09-27 08:28) [36]

> [33] alabama01 (27.09.06 02:28)

> Если писать в таблицу все продажи (одна запись - одна продажа)
> , через год (если не удалять продажи) поиск свободного места
> будет занимать довольно приличное время особенно на слабеньком
> сервере

Придумываешь ты. 100 автобусов в день по 60 человек 365 дней в году = 2190000 записей. Детский лепет при наличии индексов.

← →
evvcom © (2006-09-27 08:28) [37]

> [33] alabama01 (27.09.06 02:28)
> > Если кассиров много будет выдавать билеты на автобус/поезд
> > id, то с битовым подходом занятости мест mesta очень часто
> > не будут совпадать с :old_mesta. Решать, конечно, барину.
> >
>
> Обновление combobox"ов у всех кассиров происходит при
> оформлении чека любым из кассиров

Т.е. сервер асинхронно извещает всех своих подписчиков (кассиров) о проданном месте? Хорошая фича.

← →
MsGuns © (2006-09-27 13:26) [38]

Все эти "лочания" незаметно превращаются в "глючения".
Прежде чем решать подобные проблемы неплохо хотя б в общих чертах познакомиться с подобными системами. Хотя бы просто поинтересовавшись как функционирует бронирование в гостинницах например у администратора. Или в тех же ж/д кассах.
Ключевое слово - "резервирование" или его варианты.

← →
Desdechado © (2006-09-27 15:48) [39]

> В числе хранятся только свободные места. При продаже все атрибуты,
> включая номер места, id рейсов, кассиров, дата и время продажи, скидки,
> накидки, суммы, фамилии, номера документов и т.д пишутся в таблицу продаж.
Зачем тогда дублировать информацию? Это же лишние проблемы.

← →
Anatoly Podgoretsky © (2006-09-27 16:03) [40]

Не надо ничего блокировать, надо резервировать для продажи. Срок резервирования ограничить.

← →
alabama01 (2006-09-28 01:22) [41]

> Sergey13 © (27.09.06 08:28) [36]

> Придумываешь ты. 100 автобусов в день по 60 человек 365
> дней в году = 2190000 записей. Детский лепет при наличии
> индексов.

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

> evvcom © (27.09.06 08:28) [37]

> Т.е. сервер асинхронно извещает всех своих подписчиков (кассиров)
> о проданном месте? Хорошая фича.

Без нее вообще беда.

> MsGuns © (27.09.06 13:26) [38]
>
> Все эти "лочания" незаметно превращаются в "глючения".
> Прежде чем решать подобные проблемы неплохо хотя б в общих
> чертах познакомиться с подобными системами. Хотя бы просто
> поинтересовавшись как функционирует бронирование в гостинницах
> например у администратора. Или в тех же ж/д кассах.
> Ключевое слово - "резервирование" или его варианты.

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

> Desdechado © (27.09.06 15:48) [39]

Для скорости.

> Anatoly Podgoretsky © (27.09.06 16:03) [40]

Как?

← →
alabama01 (2006-09-28 03:04) [42]

Решение найдено следующее:
пишем dll active-x, которая ,будет работать на сервере и ХП1, которая будет ее запускать. Регистрируем на сервере dll.
Далее:
1) форма продажи при открытии, в отдельном потоке, создает ожидание события Event1;
2) после выбора места в комбобоксе со свободными местами запускаем ХП1 с передачей в параметрах id рейса и номера выбранного места.
3) ХП1 запускает в dll функцию, которая смотрит наличие данного свободного места и, если оно действительно свободно, то записывает его как занятое, и возвращает новое число со списком свободных мест, если же оно уже занято, тогда - 0. Все это описано в критической секции.
4) Если результат не 0, тогда функция сбрасывает событие Event1.
5) Форма продажи получает сброс события и новое число с местами, затем смотрит, если на ней есть такой рейс, то пересчитывает число в места и перересовывает комбобокс с новыми свободными местами.
6) форма продажи снова создает ожидание события Event1;

← →
atruhin © (2006-09-28 09:24) [43]

А что будет при обрыве сети, и если место заблокированно?

← →
Sergey13 © (2006-09-28 09:27) [44]

> [42] alabama01 (28.09.06 03:04)

А сколько у тебя кассиров?

← →
alabama01 (2006-09-28 10:10) [45]

> atruhin © (28.09.06 09:24) [43]
>
> А что будет при обрыве сети, и если место заблокированно?
>

Я несколько упрощенно описал. Помимо описанного, ХП1 пишет это место, id рейса, и id копии программы в таблицу зарезервированных мест.
Каждая копия программы пишет себя с определенной периодичностью в специальную таблицу. Триггер этой таблицы смотрит все записи, у которых превышен период ожидания и считает эту копию "отломившейся". Соответственно удаляет все последствия потери связи.

> Sergey13 © (28.09.06 09:27) [44]
>
> > [42] alabama01 (28.09.06 03:04)
>
> А сколько у тебя кассиров?

Пока трое. Количество будет расти.

← →
Sergey13 © (2006-09-28 10:25) [46]

> [45] alabama01 (28.09.06 10:10)

> Пока трое. Количество будет расти.

До 5? До 6?
Я бы не стал заморачиваться на вариант из [42] alabama01 (28.09.06 03:04), а сделал, как советуют, нормальное резервирование.

← →
MsGuns © (2006-09-28 12:12) [47]

>alabama01 (28.09.06 03:04) [42]
>Решение найдено следующее: пишем dll active-x..
...
>Я несколько упрощенно описал.

Засстрелиться...

← →
Плохиш © (2006-09-28 13:27) [48]

> Засстрелиться

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

← →
ANB © (2006-09-28 14:12) [49]

Я бы посмотрел в сторону доводки интерфейса и отказа от комбобокса. Пример - я прошу 2 билета РЯДОМ. Однако, если не учитывать конфигурацию мест, то 2 места подряд по номерам не всегда будут рядом. Видел я кассу в кинотеатре. Там прямо схема зала и кассирша кликает по свободным местам, резервируя места. Если у нее старая картинка, то при клике на уже занятом другой кассиршей месте, вываливается мессага и ячейка перекрашивается. Резервированные места кладутся в корзину и при продаже уже заносяться в билеты. Очень удобно.

← →
Anatoly Podgoretsky © (2006-09-28 19:39) [50]

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

← →
alabama01 (2006-09-29 01:41) [51]

> Sergey13 © (28.09.06 10:25) [46]
> Я бы не стал заморачиваться на вариант из [42] alabama01
> (28.09.06 03:04), а сделал, как советуют, нормальное резервирование.
>

Не больше, наверное. Но сообщения о занятости места сильно досаждают. Даже мне, когда отлаживал.

> MsGuns © (28.09.06 12:12) [47]
>
> Засстрелиться...

Этот алгоритм только кажется сложным. При ближайшем рассмотрении - все не так страшно. Зато нет никаких дополнительных сообщений о недоступности выбранного места. Выбранное - всегда есть. И таблицы лочить не надо.

> Плохиш © (28.09.06 13:27) [48]

На экране ничего не мелькает.

> ANB © (28.09.06 14:12) [49]
>
> Я бы посмотрел в сторону доводки интерфейса и отказа от
> комбобокса.

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

> Anatoly Podgoretsky © (28.09.06 19:39) [50]
>
> Визуальный выбор всегда удобен, и вот для этой схемы подходит
> оповещение клиентов. Зарезервирован/продан/возвращен. Для
> продажи в кинотеатрах особенно, для продажи на поезда требуется
> делать немного иначе, поскольку вагонов много и они разные.
>
>

Вот и я о том же.

← →
MsGuns © (2006-09-29 11:54) [52]

>alabama01 (29.09.06 01:41) [51]
>Этот алгоритм только кажется сложным.

Я не сказал, что он сложный. Я сказал, что можно стреляться, если не получается достаточно простую задачу решать достаточно простыми же методами. Каким боком тут ActiveX и что здесь делает DLL ?

>И таблицы лочить не надо.

Чисто профессиональный вопрос: откуда возникло это слово "лочить" и где надо ставить ударение ? И ЧТО ОНО ЗНАЧИТ ?
Я было подумал, что это от слова Lock (замок, запор), но оно читается как "лок", а не "лочь". Ну и попутно поясните несведущему, как вы собираетесь БЛОКИРОВАТЬ записи или даже целые таблицы в системах с большой транзакционной конкурентностью (ну это когда вероятность того, что на "одно место" будет в течение относительно небольшого периода времени сделано более одной заявки, достаточно высока) и каким образом ActiveX или тем более DLL компенсирует Вам отсутствие соответствующих реальных механизмов блокирования на сервере ? Ибо большинство серверов понятие "блокировка" понимают несколько иначе, чем Вы ;))

← →
ANB © (2006-09-29 12:31) [53]

> Отказался потому, что (это условие заказчика), перевозчик
> может без предупреждения, в последний момент заменить автобус

Каким боком это к комбобоксу ?

Значится, предлагаю следующее решение :

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

← →
MsGuns © (2006-09-29 13:32) [54]

>ANB © (29.09.06 12:31) [53]

Не канает - актива нетути и ничего не "лочится" ;)))

← →
Petr V. Abramov © (2006-09-29 13:41) [55]

я б вообще от всяческих комбиков пр. вещей, связанных с мышиной возней отказался.
Большинство людей просят БИЛЕТ, а не "билет на такое-то место" Исходя из этого: по нажатию какой-то кнопки в правой части клавиатуры блокируем место чем-нибудь типа select ... for update, печатаем билет и быстро commit.
примерно по тому же принципу действуем, если просят N билетов или N рядом.
и уж для оставшихся 1% принципиальных делаем возможность ввести "билет на 19-е место". После числа цифры "19" (т.к. нажать 2 кнопки справа клавиатуры быстрее, чем крутить комбик, да еще с в общем случае неактульными данными) либо вылезает билет, либо сообщение "занято". И уж на совсем редкий случай, когда начнут говорить "а перечислите, какие есть" делает что-то типа комбика ( ессно, без гарантии, что пока кассир будет перечислять свобобные места, они не уплывут)
таким образом еще и исключается ситуация, когда место в непонятном состоянии (и не продано, и не свободно, с большими шансами, что автобус уйдет), а кассир занят выдачей жалобной книги.
тупо, но эффективно

я б вообще от всяческих комбиков пр. вещей, связанных с мышиной возней отказался.
Большинство людей просят БИЛЕТ, а не "билет на такое-то место" Исходя из этого: по нажатию какой-то кнопки в правой части клавиатуры блокируем место чем-нибудь типа select ... for update, печатаем билет и быстро commit.
примерно по тому же принципу действуем, если просят N билетов или N рядом.
и уж для оставшихся 1% принципиальных делаем возможность ввести "билет на 19-е место". После ввода числа "19" (т.к. нажать 2 кнопки справа клавиатуры быстрее, чем крутить комбик, да еще с в общем случае неактульными данными) либо вылезает билет, либо сообщение "занято". И уж на совсем редкий случай, когда начнут говорить "а перечислите, какие есть" делает что-то типа комбика ( ессно, без гарантии, что пока кассир будет перечислять свобобные места, они не уплывут)
таким образом еще и исключается ситуация, когда место в непонятном состоянии (и не продано, и не свободно, с большими шансами, что автобус уйдет), а кассир занят выдачей жалобной книги.
тупо, но эффективно

сорри да дубль.
и еще - сначала коммит, потом печатаем, иначе при глюке после печати транзакция может и откатиться, и 2 билета на одно место обеспечены.

> я б вообще от всяческих комбиков пр. вещей, связанных с
> мышиной возней отказался

не, это однозначно надо чтобы с клавы работало. Жмет кнопку заказа - первые свободные места автоматом могут заказываться (можно заранее вводить нужное количество мест). если бабушка начинает канючить "мне впереди или сзади", дать возможность поменять места. Но - саначала заказ, потом продажа. т.е. минимум 3 состояния свободно, заказано, продано.

> ANB © (29.09.06 13:48) [58]
> минимум 3 состояния свободно, заказано, продано.
ОДНОЗНАЧНО! хотя бы для корректного отслеживания ситуации "билеты кончились"

>Petr V. Abramov © (29.09.06 13:54) [59]
>> минимум 3 состояния свободно, заказано, продано.
> ОДНОЗНАЧНО! хотя бы для корректного отслеживания ситуации "билеты кончились"

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

Запостил, а потом вспомнил:
еще одно - "возврат"

← →
alabama01 (2006-10-02 04:18) [63]

> MsGuns © (29.09.06 11:54) [52]
>
> >alabama01 (29.09.06 01:41) [51]
> >Этот алгоритм только кажется сложным.
>
> Я не сказал, что он сложный. Я сказал, что можно стреляться,
> если не получается достаточно простую задачу решать достаточно
> простыми же методами. Каким боком тут ActiveX и что здесь
> делает DLL ?

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

> Чисто профессиональный вопрос: откуда возникло это слово
> "лочить" и где надо ставить ударение ? И ЧТО ОНО ЗНАЧИТ
> ?

Лочить = блокировать. Откуда возникло - сказать трудно. Скорее всего потому, что "лочить" звучит лучше, чем "локить", хотя это спорно.

> Ну и попутно поясните несведущему, как вы собираетесь БЛОКИРОВАТЬ
> записи или даже целые таблицы в системах с большой транзакционной
> конкурентностью (ну это когда вероятность того, что на "одно
> место" будет в течение относительно небольшого периода времени
> сделано более одной заявки, достаточно высока) и каким образом
> ActiveX или тем более DLL компенсирует Вам отсутствие соответствующих
> реальных механизмов блокирования на сервере ? Ибо большинство
> серверов понятие "блокировка" понимают несколько иначе,
> чем Вы ;))

Я не собираюсь их блокировать.
Вместо блокировки таблиц применяется критическая секция в длл.
Эффект тот же, однако таблицы не блокируются. Поскольку проверка на свободные места осуществляется на стороне сервера - скорость очень высокая, примерно 0,030 сек. первый раз, и 0,002 сек. последующие.

> ANB © (29.09.06 12:31) [53]
>
>
> > Отказался потому, что (это условие заказчика), перевозчик
> > может без предупреждения, в последний момент заменить
> автобус
>
> Каким боком это к комбобоксу ?

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

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

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

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

> Нет никаких сообщений о занятости, выбранное место всегда
> есть в наличии.

ИМХО. Зуб даю, что таки кассиры умудрятся наделать кучу дырок (и будет неудобно продавать места рядом, что вызовет недовольство пассажиров) или продать два билета на одно место.
ЗЫ. критическая секция в DLL будет работать только в рамках одного процесса.
По поводу визуальности выбора - вовсе необязательно вообще заполнять конфигурацию мест в автобусах. Можно выводить и прямоугольником. хоть 8*8. :)

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

"Королей мешаю я с тузами, и с дебютом путаю дуплет" (с)
Это по поводу "критических секций" в частности, и каши в голове автора - в целом

← →
alabama01 (2006-10-03 01:52) [68]

> sniknik © (02.10.06 09:43) [64]

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

Нигде я такого не говорил. Наоборот, мы использовали почти все высказанные советы. И резервирование, и откат, и обновление данных для кассира, почти все, что тут обсуждалось. Еще раз повторяю, dll потребовалось вводить для того, чтобы, коротко говоря, оповестить все копии программы о произошедших изменениях в количестве свободных мест, без дополнительного уведомления кассира посредством вывода сообщений. Один что-то сделал, у других это тут же отразилось. И если у кассира почти мгновенно отображается измененная информация, то он в принципе не может выбрать занятое место, во всяком случае так было задумано. Что тут не ясно? Все остальное - как обычно. А по поводу пресловутых "критических секций" так вот что скажу: как известно, код, написанных в этих секциях одновременно может выполнить только один, так вот в этом коде и определяется количество свободных мест и, если надо, изменяется их количество и резервируется место для продажи, оповещаются другие копии программы. Действительно, это используется как аналог блокировки.
Все это работает. Никакой каши в моей голове нет, и ничего я никому не "замазываю" и самообманом не занимаюсь.
Один выявленный недостаток - это то что не видно, есть ли места зарезервированные, но не проданные. Чуть попозже прикрутим визуальное отображение, свободные одним цветом, зарезервированные другим, проданные третьим. В самом деле, как высказался ANB © (02.10.06 10:09) [65], это можно сделать схематически и не заморачиваться на реализм.

> [68] alabama01 (03.10.06 01:52)
> как известно, код, написанных в этих секциях одновременно
> может выполнить только один

У тебя все кассиры работают на одной машине с одним и тем же экземпляром приложения?

> Никакой каши в моей голове нет

Ну как же нет? Ты же не понимаешь, что такое крит.секции!

> Нигде я такого не говорил.

alabama01 (29.09.06 01:41) [51]
> Зато нет никаких дополнительных сообщений о недоступности выбранного места.
> Выбранное - всегда есть.
> И таблицы лочить не надо.

alabama01 (02.10.06 04:18) [63]
> ...
> Я не собираюсь их блокировать.
> Вместо блокировки таблиц применяется критическая секция в длл.

ага, а у меня бабушка балерина...

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

p.p.s. повторюсь, мне совершенно пофигу как вы там сделали, ваши проблемы, но судят о тебе и том что вы сделали по тому что ты показал/расказал сдесь... и показаное сдесь, логика, вовсе не такое радужное как заверения о работоспособности алгоритма.
и еще, если чтото использовал то оповести автора в ветке, этого как то приличия требуют. а не (смысл, краткое содержание ветки) "все фигня, мы пошли своим путем. сделали круче!, а когда "приперли", мы все использовали! свои только заморочки, зачем против своего же выступаете?"... некрасиво выглядит.

> код, написанных в этих секциях одновременно может выполнить
> только один,

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

>alabama01 (03.10.06 01:52) [68]
>Еще раз повторяю, dll потребовалось вводить для того, чтобы, коротко говоря, оповестить все копии программы о произошедших изменениях в количестве свободных мест

Что значит "оповестить копии" ? Как Вы не можете понять, что с т.зр. БД абсолютно фиолетово в каком "родстве" находятся два клиента-конкурента, являются они "копиями" или не являются. И опять же неясно, причем тут длл, если эти "копии" сидят на разных компах (применительно к удаленным сетям так и врвзных городах). Или у Вас пять операторов в реале сидят за одним компом и работают с пятью экземплярами ПО ? (Хотя и в этом случае тайна - зачем тут длл ибо ничего конкретно не решает)

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

Неясно все, кроме одного - Вы совершенно не предстваляете себе МЕХАНИЗМ РАЗРУЛИВАНИЯ КОНФЛИКТОВ. Что значит "мгновенно отображается" ? Вы уверены, что в случае упомянутой мною выше гостинничной системы изменение в гостиннице Россия ТУТ ЖЕ отобразится на дисплее ВСЕХ администраторов всех других гостинниц ? А если даже отобразится, Вы уверены что это им НУЖНО ?
Еще раз повторяю, - обратитесь к людям, имеющим опыт работы с подобными системами, например, кассирам касс, операторам банков, администраторам гостинниц и т.д. Поговорите с ними и у Вас многое "прояснится на доске".
Главным образом то, что проверка на резервирование или бронирование (как угодно) должна выполняться не при ПРОСМОТРЕ "свободных" мест, а непосредственно при этом самом роезервировании или бронировании.
ИМХО, вот этот момент почуму-то никак до Вас не дойдет. Вот это-то механизм "блокировки" повторного резервирования обеспечит любой нормальный сервер безо всяких Ваших "защищенных блоков", дээлелек, активиксов и прочих "научных" терминов, коими Вы ткт так обильно сорите. С помощью примитивных триггеров хотя бы.

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

Ничего не понял. А Вы ?

>Никакой каши в моей голове нет

Увы, что есть, то есть.

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

Это не недостаток. Это НОРМАЛЬНАЯ СИТУАЦИЯ. Когда отображаемая
на дисплее информация содержит устаревшие данные. Для этого собственно и служит регулярное, через определенный момент времени обновление информации. Механизм которого можно наглядно увидеть на табло любого вокзала или аэропорта. Нет ничего страшного, когда оператор пытается "выписать" билет на конкретное место, а система ему отказывает, т.к. с момента псоледнего обновления его экрана кто-то в Мухосранске или Урюпинске уже выписал билет на это место. Кстати, а я вот так и не понял, какая мне, как клиенту, разница, какой НОМЕР места мне будет выписен, например 17 или 29 ? Главное, чтобы оно было в вагоне нужного класса и нижнее. Или я чего-то недопонимаю ?

← →
saxon (2006-10-03 14:15) [73]

Как предположение: длл наверное что то типа апп-сервера или он и есть (т.е. она не на клиентах работает).

> Кстати, а я вот так и не понял, какая мне, как клиенту,
> разница, какой НОМЕР места мне будет выписен, например 17
> или 29 ? Главное, чтобы оно было в вагоне нужного класса
> и нижнее. Или я чего-то недопонимаю ?

17 - подальше от туалета, например (ночью слышно как люди туда - сюда) и вообще, что не человек то свои заморочки. :)

я делал трехзвенкой:
в выборку свободных мест добавил калк поле... поле заполняется на сервере из Memory таблицы блокировок: Место, оператор... если запись имеется возвращается id заблокировавшего если не нуль значит ЗАНЯТО, иначе свободно...
Если оператор хочет заблокировать место то вызывает соотв метод сервера - разблокировать может только сам оператор (входят в систему по id) или админ/глав кассир
блокировки в базе не зранятся, а хранятся в памяти

> [74] Slym © (04.10.06 04:50)
> в выборку свободных мест добавил калк поле... поле заполняется
> на сервере из Memory таблицы блокировок

Ты путаешь понятие калк поля с чем-то еще. Если поле возвращается с сервера, то это уже не калк в терминах Delphi, несмотря на то, что оно все-таки вычисляется, но вычисляется-то на сервере!

> блокировки в базе не зранятся, а хранятся в памяти

Изобретение велосипеда, хотя может для трехзвенки это в порядке вещей?

evvcom © (04.10.06 8:22) [75]
Ты путаешь понятие калк поля
Калк поле оно и в африке Калк поле... на сервере оно калк а на клиенте ридонли поле

← →
alabama01 (2006-10-05 01:00) [77]

> MsGuns © (03.10.06 13:25) [72]

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

Соглашение о терминах:
NTserver - сервер NT или его потомки, типа 2000 или 2003.
SQLserver, СУБД - MSSQLserver, установленный на NTserver.
Приложение-клиент, приложение, программа - программа, работающая на клиентской машине, с которой работают кассиры.
БД - база данных, с которой работает приложение-клиент.
"приложение смотрит" - приложение, работающее на клиентской машине выполняет запрос к БД, с целью получить данные для выполнения необходимых ему действий. В необходимых случаях с блокировкой соответствующих таблиц.
Обновление данных - запрос к БД, с целью получения данных, актуальных на текущий момент времени.

Предлагаемый Вами вариант понимаю примерно так:
(1) Кассир К1 резервирует для продажи место №1 на рейсе Р1, у которого количество мест равно, скажем, 10.
Реализуется, например, как запись id рейса Р1, места 1, id кассира в таблицу зарезервированных мест.
(2) Берет деньги, считает, препирается/консультирует пассажира, словом, тратит время.
(3) В промежуток времени (2) кассир К2 тоже хочет продать билет на рейс Р1.
(а) При выборе рейса Р1 приложение-клиент смотрит, (в данном случае с блокировкой), проданные + зарезервированные места, считает свободные и предлагает их для продажи кассиру К2, т.е. обновляет данные. У К2 место №1 будет отображено как зарезервированное. Остальные 9 доступны для резервирования и продажи. В этом случае - все нормально.
(б) Если же у К2 рейс Р1 уже был выбран, то место №1 у него считается доступным для продажи. Т.е. у него на экране устаревшие данные. При попытке выбрать место №1 приложение смотрит, что это место зарезервировано, выводит сообщение кассиру К2 и обновляет данные. Кассир К2 выбирает место №2 и резервирует для продажи.
(4) В это время пассажир кассира К1 передумал ехать на 1 месте, а решил на 2. У К1 это место пока отображается как свободное. При выборе места №2 место №1 удаляется из таблицы зарезервированных, а для К1 повторяется вариант из (3б).
(5) при продаже соответствующее место удаляется из зарезервированных, и прописывается в таблицу продаж, в одной транзакции.
(6) При простое, когда никто ничего не продает, приложение периодически (с каким, кстати, периодом?) обновляет данные о рейсах.
(7) и так далее.
Если я Вас неправильно понял, поправьте меня. Затем продолжим.

> [77] alabama01 (05.10.06 01:00)

6) Зачем? Обновление, ИМХО, должно быть
а - при первоначальном запросе
б - при коллизии
в - по требованию кассира

>alabama01 (05.10.06 01:00) [77]

Эк Вас задело, что Вы целый роман написали ;)

Резюме подавляющего кол-ва критических реплик в том, что НЕ НАДО НИЧЕГО ПРЕДПРИНИМАТЬ ВО ИЗБЕЖАНИЕ КОНФЛИКТОВ НА КЛИЕНТЕ ИБО ВСЕ РЕАЛИЗУЕТСЯ ДОСТАТОЧНО ПРОЗРАЧНО И НАДЕЖНО НА СЕРВЕРЕ.
При этом не уточняется какой сервер. В принципе - любой, в т.ч. и локальные СУБД. Главное - это централизация кода распределяющего непосредственно в БД "места"

Описанный Вами в [77] "конфликт" почти на 100% совпадает семантически с "классическим" примером транзакций, приводимых в куче книг по БД (имеется в виду банковская операция по переводу денег с одного расчетного счета на бругой).
Вот почему я и советовал Вам прежде чем углубляться в тонкости реализации (защищенные блоки, динамические библиотеки, COM-интерфейсы и т.д.) ознакомиться более внимательно с означенной проблемой и путями ее решения.

Продажа билетов несколькими кассирами Найти похожие ветки