Есть справочник. В нем ТЧ. В ТЧ для каждой строки есть рекв. Номер, он уникален в пределах всего справочника. При создании нового эл-та справочника я должен узнать, значение последнего использованного номера. Где его лучше хранить, в регистре сведений? Как сделать кошерно?

А запросом некошерно узнавать?

(1) пробежаться в запросе по всем элементам спр. и по их ТЧ?

(0) А как быть с пустотами, если некоторые элементы удалили и номера освободились?

(2)МАКСИМУМ уже отменили?

(1) в принципе справочник не должен сильно разрастись, хай тэк и будет

+(3) Т.е. вопрос в том, зачем хранить последний номер?

(2) Зачем? Запрос максимального значения поля "номер" напрямую из табличной части.

(3) Когда "пустота" закончится что будешь делать?

(3) в моем случае пустоты пропускать нужно

(9) Тогда см (4) и (7)

(4) да, я это предполагал

(4),(11) блокировать весь справочник не забудь... иначе будут проблемы

(11) На самом деле запись номера в регистр и считывание его запросом, на мой взгляд, более затратная операция чем просто запрос к таблице табличных частей справочника. Естественно надо подумать на индексами по полю Номер

(12) блин, наверное, да. Но блокировками до этого на практике пользоваться не приходилось ни разу. Как бы не накосячить. Накидал такой код:

Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить("Справочник.МойСправочник");
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
Блокировка.Заблокировать();

Правильно ли я понимаю, что блокировка будет работать до конца той процедуры, в которой она описана? И в рамках этой процедуры я спокойно могу изменять элементы справочника?

UUID не предлагать?

(14) блокировка работает до конца транзакции

(15) +1
Если не принципиально именно число, записывай лучше UUID

(0) Я бы сделал подчиненным справочником. И забил бы на все блокировки, уиды и прочее. Оно бы тогда - само.

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

(0) это не ТЧ, а подчиненный справочник

(15), (17) такой вариант к сожалению не подходит, нумерация своя

(21)
а может (20)?

(21) Эти твои уникальные номера - это ссылочный тип. Любые попытки симулировать ссылочный тип при помощи необъектных данных и чисел обречены на оглушительный провал и бездарную потерю времени и трудовых ресурсов.

(23) а почему это ссылочный тип обязательно?

(18) (20) в моей конфе уже есть готовый справочник с готовой ТЧ. Я его модернизирую.

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

(20) +1

(25) заведи справочник "Исполнители" и подставляй уникальные значения из него, или дополнительный документ/справочник если нужно "Контрольная карточка исполнителя"

(26) т.е. будет у меня справочник НумерацияКонтрольныхКарточек, рекв. Наименование - это номер. так ведь пойдет?

(27) По коду уникальность. Код и есть номер

(28) Ну как бы мне надо, чтобы номер начинался с 34586 и шло по-порядку. а поле Код оно идет по-порядку, но с нуля. И заставить его нумероваться 34586 я так понимаю нельзя

биля. давай без костылей.
делай (20).

(29) не понял, а номер для самого первого поставить 34586 кто мешает то? и пойдет он по порядку

(30) пока не понимаю идею с подчиненным справочником. Свою задачу описал в (25) и нужно чтобы номер шел с 34586

(32)
ТЧ Исполнители переводи в подчиненный справочник Исполнители,
уникальность во всем справике, тип число.

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

(25) Я так и думал, что это для печатной формы. Генерируй номер каждый раз при печати в зависимости от уже введенных контрольных карточек и ТЧ.

(33) как-то это сложно. Мой справочник (Контроль) сейчас не пустой. Для существующих элементов (у них новый реквизит ТЧ будет пустым) нумерация останется по-старому (см (25)).

Мне больше нравится идея создать независимый справочник НумерацияКК. Присвоить первому элементу Код 34586, и эл-ты этого справочника подставлять в реквизит ТЧ справочника Контроль. Остался вопрос: мне ведь не нужно пользоваться блокировками, чтобы гарантировать уникальность кодов в справочнике НумерацияКК?

Блажь

(37) +
Хомячки развлекаются.

У хомячков есть база в аксессе и контрольные карточки они раньше вели там. Когда их перевели на 1С о нумерации почему-то не подумали. Но теперь они хотят вернуть старую нумерацию. А на то какие номера у карточек существующих в 1Ске им пофиг. Их номера заведомо меньше числа 34586, с которого будет возвращена старая нумерация.

(25) >Но пользователи захотели чтобы этот номер формировался автоматом по-порядку, начиная с конкретного числа.

Зачем? о_0
что они с этим номером делать будут такого, чего не могут делать с тем, что есть?

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

(40) > (39)

руками. Но - не суть

(42) там нет ответа, зачем эти номера и чего они не могут сделать с новыми номерами такого, чего могли со старыми.

Аргументы типа "мы так не привыкли" и "нам так хочется" достойны только ответа: "привыкайте" и "хотеть вы будете дома, а на работе вы будете делать то, что нужно компании и так, как ей это нужно".

(44) хз, видимо они не хотят быть привязанными к конкретной программе, еще они параллельно ведут эту (старую) нумерацию в бумажном журнале

(46) тебя дураки нагружают дурацкой работой и ты из за этого ломаешь хорошиую архитектуру, превращая ПО в УГ. Одумайся.

(47) сделать то о чем они меня просят не настолько трудозатратно, чтобы я им отказал. "Стандарная" нумерация (см (25)) никуда не исчезнет ее всегда можно вернуть.

(48) это бессмысленно делать

(48) >> сделать то о чем они меня просят не настолько трудозатратно

зачем тогда эта тема?

(50) люди, плиз, просто скажите мне, сделать то, что я описал в втором абзаце (36) прокатит? И тема будет закрыта.Сама задача описана в (25).

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

(46) Печатай журнал из 1С, укажи номер с которого начинать

+(52) но это все делать вообще не надо, т.к. это деланье того, что уже и так сделано - уникальный номер уже и так есть - он состоит из двух компонентов просто.

(52) да, только программно, ведь нумерация будет вестись автоматически. спс.

(55) блин, да она уже ведется... эх...

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

(54) этот номер печатается в макете контрольной карточки на бумаге. Люди хотят видеть на бумаге "свою старую" нумерацию, которую вели в аксессе

(58) у "хотят" есть какое-то экономическое обоснование? Или им просто для эстетического удовольствия?

(59) я работаю на фикси

UUID (элемента) + номер строки - не подойдек в качестве уникального номера?

(61) это уже реализовано и работает, но автор на фикси работает - ему за думанье не платят

(62) (61)
Пользователей с их задумками конечно надо отшивать по возможности, но заставлять тёток-кладовщиц работать с карточками с нумерацией вида f3c8085a-ae34-4b34-a6a1-7912e8539d72-10 это совсем жестоко