хранимый счетчик для нумерации кодов #779081

всем привет! ситуация следующая: есть справочник в 1С 8.3, настроен его обмен с dbf-файлом, т.е. новые элементы справочника скидываются в этот файл. вопрос: как организовать хранимый счетчик для этого файла? т.е. чтобы нумерация в этом файле продолжалась своя. в принципе сейчас сделал через константу, считываю текущее значение, плюсую 1 и передаю полученное значение (записывая в константу это значение). смущает 2 момента: 1)производительность 2) уникальность счетчика (что будет если одновременно будут обращаться к константе и не получится ли для 2 элементов 2 одинаковых кода).

Скорость нормальная, а второй вопрос - блокировки для кого люди придумывали?

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

Отвыкай от понятий 77

И где это регистр сведений в 7.7 ?

Регистр бухгалтерии и план счетов еще нужен. Для учета оборотов монотонно возрастающего счетчика.

А где в 8 общая таблица констант?

В голове у программиста. Там и происходят основные блокировки =)

Вроде как с какой-то версии, каждая константа в отдельной таблице стали.

Насколько я помню, основная форма констант - одна, а всё остальное у каждой константы своё.

Да, где-то с 8.0 приблизительно

А форма тут при чём? Если мы о таблицах?

А где у константы "Заблокировать" ?

Хотя, согласен, при открытии транзакции (РежимУправленияБлокировкой.Управляемый) пофиг, что константа, что регистр, что справочник.

Да, генераторы в 1С используются только для документов, да и то там никто уникальность не обещает.

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

А не в 1с?

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

Самая неприятная фамилия для изобретателя - Велосипедов

В SQL-сервере есть такое понятие, как генератор, который вне зависимости от транзакций выдаёт значения возрастающего счётчика - он один может выдавать значения нескольким клиентским сеансам параллельно и уникально.

Ничоси!

Согласен - в случае проще один раз получить уникальный счётчик, а далее, в файле использовать другой счётчик записей, который будет возрастать.

Там в , в предложении "чтобы нумерация в этом файле продолжалась своя" слово "своя" настораживает. Чорд его знает, что ТС хочет.

С ораклом не путаем?

FireBird никуда не Oracle, но тоже сию замечателькую фичу имеет.

Пока мы тут обсуждаем, он уже всё написал, сдал и забыл как страшный сон.

В оракле это последовательность. Он так firebird называет =)

В FireBird это называется GENERATOR и функция GEN_ID(ИмяГенератора,КоличествоЗначений) - очень удобная вещь. В 1С реализуется через внешнее соединение к той же самой базе - тогда можно независимо транзакции "дёргать".

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

пока не понятно, на кой ляд делать в онлайне то, что в онлайне не нужно

Задачу решает , а мы тут просто рассуждаем, как сделать это в Online. Просто, очень сомнительно, что выгрузку в dbf-файл будут делать параллельно из двух сеансов и одному получателю ^_^

Итого получается - чтобы выгружать в dbf надо поставить firebird. Я правильно понимаю? =)

Запросто. С одно компа под одним пользователем запускают две 1с, потому что ваша выгрузка тормозит

Вы ещё скажите, что два процесса пишут в один dbf-файл по очереди и не ошибаются ? Я этого не говорил, я просто говорил, что есть системы, где уникальное значение счётчика - не проблема.

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

Сколько той транзакции будет, чтобы прочитать и записать константу? Юзер не успеет осознать даже.

Ух ты, сколько интересного можно узнать о работе транзакций!

Где-то кто-то говорил про один файл?

"Все новые элементы скидываются в dbf-файл" - разве их много ?

Собственно накуа там счетчик нужен?

Зависит от сценария Например пользователь выгружает новые элементы справочника, созданные вчера и позавчера в разные файлы.

Интересно, а номер файла в качестве счётчика использовать нельзя ?

ТС какую то фигню устроил на пустом месте. Не понятен механизм синхронизации "новые элементы справочника" с записями в dbf куда они пищутся. Что произойдет при перезаписи или после копирования и записи "элемента справочника"? Что будет после удаления? Что будет если файл dbf тупо грохнули? Цель всего этого изврата какая?

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

Не понял. Счетчик чего? Для имени файла? Для объектов в файле?

для новых записей в файле

Этот системный код в базе дбф - это какой-то идентификатор?

просто текстовое поле. число с лидирующими нулями.

грубо говоря есть записи 1,2,3,4,5,6. в 1С создаем 2 элемента справочника: 7 и 8. скидываем в файл. получаем 1,2,3,4,5,6,7,8 вопрос был, чтобы не получилось ситуации когда 1,2,3,4,5,6,7,7

Я не про тип. Для чего используется? Почему нельзя использовать GUID объекта? В таком случае у тебя идентификация сможет работать "в обоих направлениях".

Терь понятно, обычная синхронизация между двумя системами. Делается через общие коды, хранить их в любой из баз проще будет в 1С. Заводишь в 1С регистр сведений вида Объект/ВидКода/ЗначениеКода и для всех существующих контрагентов заполняешь нужными кодами как в DBF они имеют. "ВидКода" это если несколько систем еще есть foxpro'шные или еще какие чтобы отличать. Далее заполняешь регистру свою так чтобы записи были уникальными и все, если код занят то берешь следующий. Т.е. или есть запись для объекта 1С или нужно ее создать взяв последний код, сделав +1, проверив на уникальность и тока потом пишем. И ничего не нуна в константах хранить когда регистр есть.

это код. уникальность записи.

ок. понял. спасиб

тогда еще один глупый вопрос - как обеспечить уникальность записи в регистре? уникальность значения кода.

Проверкой на уникальность до и после записи ))

ясно. тогда другой вопрос. в чем существенная разница между хранением последнего кода в константе и записи текущего значения в реквизит элемента (как я сделал) и через регистры?

Видимо подразумевается универсальность. Можно для любого справочника/документа один регистр использовать.

но это не значит что через константу неправильное решение?

Думаю, и то и то имеет право на жизнь, если правильно сделано.

Любое решение, удовлетворяющее критериям задачи в ТЗ - правильное.

а чем Код элемента справочника Контрагенты не подошел?