Всем привет.

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

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

В стандартных объектах нумерации вроде есть какие-то подобъекты, но там, кажется, длина ограничена 6 символами - этого маловато для номера документа.

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

Какие могут быть решения?

вызывай ФМ DB_COMMIT. собственно когда number_get_next делается, тоже неявный commit происходит

хотя на мой взгляд постановка задачи странновата...

Постановка странновата, но уж какая есть, такая есть. Сейчас это не изменить.

А что DB_COMMIT изменит? Я ж говорю, мне нужно чтобы commit-а при генерации нового номера не было.
Насчет number_get_next, пр-моему нет там commit. Нужно проверить.

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

если number_get_next будете тестировать учтите надо брать объект без буферизации

ещё есть такая идея:

так вот слегка извратившись в символьное поле длиной 6 можно затолкать 12 цифр, для этого в сапе спец тип данных придуман - P

Вообще, db_commit тоже хотелось бы избежать.
А не знаете, можно ли вызывать ФМ в отдельном процессе (RFC) синхронно и при это чтобы не было неявного commit при вызове?

Если самих документов немного, то можно автоматически создавать объекты (и диапазоны) нумерации с помощью групп функций SNR1 и SNR2

Это с какой стати неявный commit происходит?

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

Самих документов много.
Я уже думаю, что написать свой потокобезопасный счетчик - хорошее решение, но надо придумать способ вынести его в отдельный процесс, чтобы commit при генерации нового номера никак не влиял на основную программу.
И вызов, естественно, должен быть синхронным.[/quote]
Почему бы тогда просто не использовать GUID для позиций?

Для позиций нужен внешний "красивый" номер, идущий по порядку и более-менее неразрывно.

Действительно был не прав.

А смысл в этом номере какой?
Как вариант решения:
Для вывода на экран просто нумеруйте позиции от 1 и так далее, а для ссылок используйте GUID или просто счётчик.

Технически смысла никакого. Я мог бы использовать и обычный счетчик. Но на такой вариант 100% будет замечание. Пользователи любят красивую нумерацио по порядку.

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

Ну тогда просто используйте принцип MAX NO позиции + 1
Выставляете блокировку позиции. Получилось - продолжаете работу, если нет - ещё плюс 1 и цикл по новой. Без всяких ФМ и отдельных потоков

Можно еще попробовать использовать shared memory object, где хранить и обновлять максимальный номер позиции.