Необходимо организовать нумерацию документов!!!

[Vit@L]

Привет всем!
Подскажите пожалуйста, как организовать нумерацию документов? Имеется складская программа (типа 1С), в ней есть документы (реализация, поступление тмц, РКО и т.д. и т.п.), БД - Firebird. В программе есть табличка NUM_DOKS, в которой хранятся значения для каждого типа документа и при создании документа это значение соответственно увеличивается на 1 (еденицу) и при создании второго документа его номер будет уже на еденицу больше. Сама программа сетевая. Вот тут и загвоздка, если бы она балы на одного юзера, то никаких вопросов. А вот с сетевой так не пройдет. Т.е. загвоздка именно в том, что могут к примеру 2 пользователя одновременно создавать один документ ну к примеру 2 манагера делают реализацию. Как быть в этой ситуации? Чтобы не получилось потом два документа с одинаковым номером? Пробовал записывать номер документа сразу же при нажатии на кнопку создания документа, но тут другая проблема. Что если пользователь не сохранит документ, а просто нажмет потом отмена, а счетчик уже увеличился. В общем помогите люди добрые. Очень надо.
Заранее спасибо!!!

[gromdel]

А не лучше номер документа делать, не при нажатии создать, а уже при нажатии сохранить?

[Аватар]

1. Создание номера в момент начала создания документа на клиенте. Если пользователь не сохранил документ сбросить на 1, но при условии, если другой пользователь в это время не увеличил еще на 1. Вероятность создания дырки уменьшается, но остается
2. Создание номера в момент записи документа на сервер. Предпологаемый номер показывать в момент начала созданиия документа на клиенте. Плохо - предполагаемый и фактический номера могут отличаться
3. В любом случае дырки неизбежны, хотя бы потому, что документы могут удаляться. И еще как удаляются на практике
4. Дырки можно забивать новыми документами, что есть плохо - вносится путанница в головы пользователей.
5. Смирись с дырками

[Serge_Bliznykov]

Что если пользователь не сохранит документ, а просто нажмет потом отмена, а счетчик уже увеличился.

А это разве проблема?

тогда рекомендую поступать так.
При записи документа в БД ЛОЧИТЬ (lock) запись в таблице NUM_DOC для нужно типа документа. (не помню, как там с блокировками в FireBird, на крайний случай заводите поле - isBlocked - и если оно .True. - ждать, пока не освободится.
Берём номер. разлочиваем запись в NUM_DOKS. Записываем документ в БД с полученным номером.


Добавлено
Ого! Три ответа за две минуты! если бы я увидел эти ответы раньше, не стал бы свой пост писать. Ибо всё уже сказано выше...

[Vit@L]

Serge_Bliznykov, нет нет, спасибо что написали. Так и поступлю, заведу поле, по которому будет блокироваться запись в таблице.
Спасибо огромное всем!!!

[Аватар]

Не думаю, что вариант с блокировкой хороший. Начал пользователь создавать документ, заблокировал что-то и ушел чай попить. Хорошо, что если на 10 минут. Другой в это время не моги документ такого же типа сделать. Как-то так получается Не?

[Vit@L]

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

[Sciv]

А нельзя написать автоинкрементный триггер и оставить все на произвол СУБД? У меня с Интербасом прокатывало когда-то

[Serge_Bliznykov]

погодите-ка. я имел в виду блокировку ИСКЛЮЧИТЕЛЬНо в момент записи/сохранения документа в БД. В этом случае клиент блокирует файлик с номерами (нужную строчку, где находится нужный тип документа), получает номер, разблокирует и выполняет запись документа с полученным номером. Пока пользователь пьёт чай с печеньками - номера у документа ещё нет, ничего не блокируется.

[Stilet]

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

загвоздка именно в том, что могут к примеру 2 пользователя одновременно создавать один документ ну к примеру 2 манагера делают реализацию

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

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