Форум » Clipper » Сквозная нумерация документов при работе в сети. » Ответить

Сквозная нумерация документов при работе в сети.

Dima: Кто и как решал этот вопрос ? В однопользовательском режиме как бы все просто. Держим для этого в базе поле с номером документа + индекс по этому полю. При добавлении документа следующий номер вычисляем так: Переключаемся на индекс (о котором писал выше) , делаем dbgobottom() и присваиваем переменной значение из поля +1 И тд В многопользовательском режиме такой механизм будет глючить

Ответов - 27, стр: 1 2 All

Сыроежка: Для платежных поручений я считывал номер последнего документа и увеличивал его на единицу.

PSP: Отдельная dbf. В ней - 1 запись. Каждое поле этой записи соответствует определенному типу документов (нумерация у разных документов своя). Перед вычислением следующего номера документа запись блокируется. Потом вычисляется следующий номер, записывается в нужное поле и запись освобождается. Это если не нужно вести историю выдачи номеров документам.

AlexMyr: Сыроежка пишет: Дя платежных поручений я считывал номер последнего документа и увеличивал его на единицу. В момент сохранения документа?


Dima: PSP пишет: Отдельная dbf. В ней - 1 запись. Каждое поле этой записи соответствует определенному типу документов (нумерация у разных документов своя). Перед вычислением следующего номера документа запись блокируется. Потом вычисляется следующий номер, записывается в нужное поле и запись освобождается. Ты читаешь мои мысли ;) Так и сделал , но есть один момент. Если накладную я не провел то она не сохраняется в программе (так заказчик хотел) и удаляется на автомате. В этом случае в нумерации будет дырка.

PSP: Dima пишет: В этом случае в нумерации будет дырка. Это разве важно? В процессе работы любого предприятия документы иногда удаляются. Так что пропуск номера - нормальное явление. Лишь бы не двоились и по хронологии все сходилось.

Dima: PSP пишет: Это разве важно? Для меня нет ;) Но у заказчика могут возникнуть вопросы если гляннет журнал накладных а там после накладной 105 идет накладная 109. Надо будет с ним перетереть. PSP пишет: Каждое поле этой записи соответствует определенному типу документов (нумерация у разных документов своя) Только не поле а запись я полагаю

AlexMyr: PSP пишет: Так что пропуск номера - нормальное явление. +1, без этого никак.

PSP: Dima пишет: Только не поле а запись я полагаю У меня - поле. Одна запись - несколько полей (по количеству типов документов). При наступлении очередного 1 января во все поля записывается 0 и нумерация начинается сначала.

PSP: Dima пишет: а там после накладной 105 идет накладная 109 Можно вести журнал регистрации операций с документами, в котором все операции (в т.ч. и удаление) будут отражены.

PSP: Dima пишет: Если накладную я не провел то она не сохраняется в программе (так заказчик хотел) и удаляется на автомате. Присваивай номер в момент проведения. Но! Что будет, если потребуется удалить уже проведенный документ? Вот тебе опять пропуск. Номер удаленного документа следующему документу уже не присвоишь - нарушится хронология.

AlexMyr: Dima пишет: Если накладную я не провел то она не сохраняется в программе (так заказчик хотел) и удаляется на автомате. Я думаю он понимает это (про дырку) раз ставит так задачу.

Dima: PSP пишет: У меня - поле. Одна запись - несколько полей (по количеству типов документов). Счаз объясню твой не верный подход ;) При таком подходе при заведении разных типов документов будет блокироваться одна и та же запись. А вот если ввести всего одно поле а по типам документов сделать записи то так будет логичнее. Заводим какой тип документа прыгаем на нужную запись и блокируем ее

PSP: Дим, она блокируется на ничтожное время. Заблокировали - Прибавили 1 - Сняли блокировку. Доли секунды. У меня записи блокируются самопальной функцией, которая ждет некоторое время, если запись уже заблокирована. Как только запись освобождается, она тут же блокируется. Так что, даже если 10 станций в одну секунду захотят получить номер документа, им придется подождать очень недолго, не более секунды на всех, имхо. Пока особого напряга за несколько лет в этом месте не возникало. Так что, я не считаю это место узким.

СевДон: ваащето заказчик не прав: если он выпустил документ во внешний мир, то потом могут прийти оттуда и устроить допрос и вот если ты справишся с проблемой "дырок" появится есчо один или даже несколько документов с таким же номером. тады попробуй проверяющим докажи шо ничего криминального фирма и не думала совершать. у меня такие ТТНки объявляются испорченными, н номер сохраняется и на него низзя выписать другую а в реестре для клиента их можно пропускать и вывести в список отдельную ведомость или прилагать к реестру копии накладных-"отказных" UPD кароче, попытайся шоб у клиента возникли сомнения в правильности собственных хотелок пишу на основании своего опыта

Dima: Сыроежка пишет: Для платежных поручений я считывал номер последнего документа и увеличивал его на единицу. В многопользовательском режиме работы такая схема будет глючить ! Могу это доказать на простом примере если нужно. PSP пишет: Так что, я не считаю это место узким Убедил Всем спасибо !!!

Vlad04: Dima А вот если ввести всего одно поле а по типам документов сделать записи то так будет логичнее. Заводим какой тип документа прыгаем на нужную запись и блокируем ее Я такой способ применяю и ещё другой - для разных документов разные счетчики

Pasha: PSP пишет: Отдельная dbf. В ней - 1 запись. Каждое поле этой записи соответствует определенному типу документов (нумерация у разных документов своя). Перед вычислением следующего номера документа запись блокируется. Потом вычисляется следующий номер, записывается в нужное поле и запись освобождается. Это если не нужно вести историю выдачи номеров документам. Хочу в letodb перенести функцию добавления записи UDF_AppendRec из hrb-модуля в сервер, с такой модификацией: Добавить в TABLESTRU поле флагов, перед go bottom опрашивать это поле в течении, скажем, секунды, если оно установлено, и затем его устанавливать, и после добавления сбрасывать. Это будет аналог FLock(), только не будут блокироваться другие операции. При этом со 100%-й гарантией ключ (номер документа) будет уникальным.

SergKis: *PRIVAT*

Pasha: См. tests/letoudf.prg, первую функцию. Ей передается в том числе управляющий индекс, и она выдает go bottom Я добавил (уже, вечером сброшу) еще проверку: if leto_TableLock( nUserStru, ..), для того, чтобы гарантировать, что 2 пользователя одновременно не сделают go bottom, так что ключ с гарантией будет уникальным.

SergKis: Для Pasha: А как начать номер не с 1, а с 1000 ? Вводить фиктивный ? У нас, совсем недавно правда отменили, надо было в налоговой получать диапозон для документов (для работы с лесом, деревом один, для торговли другой ...), т.е. для таблиц надо переодически переустанавливать нумерацию (как кончается выделенный диапозон). Клиент на Hb 2.0 сервер xHb. На последние версии пока нет времени.



полная версия страницы