Форум » 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. На последние версии пока нет времени.

Pasha: Я эти средства делал немного для других целей, для гарантированного обеспечения уникального ключа. А начать с 1000 проще простого: dbAppend() Field->Numer := 1000 и можно затем использовать описанные выше средства.

PSP: Pasha пишет: См. tests/letoudf.prg, первую функцию. Спасибо. Посмотрю.

SergKis: Pasha пишет: Я эти средства делал немного для других целей, для гарантированного обеспечения уникального ключа. А начать с 1000 проще простого: dbAppend() Field->Numer := 1000 Т.е. решение фиктивный документ, но это не есть красиво. Может добавить в функцию еще параметры (управляющий индекс первый) диапозон вхождения: второй (min), третий (max). Тогда если 1 не входит в диапозон получим 1001. Или как-то иначе. Ведь решение гарантированного обеспечения уникального ключа - AUTOINCREMENT

Pasha: PSP пишет: Спасибо. Посмотрю. Только там еще версия без проверки. С проверкой я скину вечером. Прогнал тест: 2 клиента одновременно добавляют в таблицу несколько сот тысяч записей с формированием ключа. Повторы не обнаружены, как и ожидалось. Погоды стоят предсказанные (С).

PSP: Pasha пишет: С проверкой я скину вечером. Да, это я понял.

Pasha: SergKis пишет: Т.е. решение фиктивный документ, но это не есть красиво. Может добавить в функцию еще параметры (управляющий индекс первый) диапозон вхождения: второй (min), третий (max). Тогда если 1 не входит в диапозон получим 1001. Или как-то иначе. Ведь решение гарантированного обеспечения уникального ключа - AUTOINCREMENT Добавлю, и еще проверку переполнения тоже. Я оставлю эту функцию в hrb, так что ее можно модифицировать для себя как угодно. А autoincrement не всегда удобно использовать. По ключевому полю в любом случае необходим индекс, а раз есть индекс - можно обойтись и без автоинкремента. Да и ключ иногда хочется сделать символьным.

SergKis: Паша, спасибо за объяснения и терпение !



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