Имя: Пароль:
1C
1С v8
Слетает нумерация при копировании базы...
,
0 max735
 
20.12.17
00:16
Уважаемые,
подскажите пожалуйста, что может быть причиной того (и как лечить), что
при копировании SQL базы 1С в копии при выписке некоторых документов и и создании элементов справочников выдаются какие-то старые номера. В результате получаю "номер не уникальный". В тестовой базе просто проставляю "правильный" номер руками и дальше все идет нормально.
Но не хотелось бы получить неожиданно подобную проблему в рабочей базе. Куда смотреть?
Спасибо.
1 France
 
20.12.17
00:18
пожалуйста.
у вас нетиповая конфа, где нумерацию втихаря делаете..
так, какая у вас конфа, и какие изменения?
2 Armando
 
20.12.17
00:22
После копирования рабочей базы в тестовую выполните в ней (в тестовой) метод ОбновитьНумерациюОбъектов().
3 France
 
20.12.17
00:23
(2) эээ... стотыщ раз копировал.. не выполнял.. что за на метод??
4 max735
 
20.12.17
00:35
(1) Конфигурация бухгалтерия предприятия, измененная, но изменения в основном новые структуры, справочники.
Да, есть такой момент, что автоматически выписывается пакет документов, при этом проверяется период и устанавливается дата из нужного периода, не руками и стандартной функцией (забыл название). Но раньше как-то эта проблема не проявлялась, возможно база разрослась...
5 tesseract
 
20.12.17
00:36
Возможно при обновлении конфы в какой-то момент слетел нумератор. Было год назад, когда добавили префикс РИБ принудительно в номер  в 1с, даже если РИБ не было и номера обрезались по последнему символу.
6 max735
 
20.12.17
00:37
(2) Спасибо, попробую.
Но хотелось бы понять суть проблемы, почему так происходит.
7 max735
 
20.12.17
00:38
(5) Проблема проявляется только на скопированной базе, в рабочей базе такого не замечено.
8 tesseract
 
20.12.17
00:43
(7) Если база файловая - там еще и висячих строк можно огрести. Копировал просто файлом, выгрузкой через бэк или через dt?
9 max735
 
20.12.17
00:47
(7) База sql. Копирую не я, а админ. Насколько я знаю, поднимает из ночного бэкапа. Но точно процедуру сейчас не скажу.
10 France
 
20.12.17
00:49
да блин, смотрите установку номера..
вот у меня в базе, я точно знаю, так нумерация ручная, и ой какая стыдная..
а ваши не стесняются..
11 max735
 
20.12.17
00:51
Такое ощущение, что какая-то периодическая запись по номерам возможно кэшируется в рабочей базе, а при архивации базы эта информация вовремя в базу не прописывается.
12 tesseract
 
20.12.17
00:52
(9) Ясн загрузи его бэк .  И сделай там тестирование целостности БЕЗ исправления. Просто ошибки посмотреть. Такое бывает при бэкэпе через SQL.

(11) Сбоят транзакции ИМХО. Надо смотреть конкретный случай, в конкретной конфигурации.
13 tesseract
 
20.12.17
00:53
(10) Кстати да может из-за очистки кэша сработать событие на установку нового номера, которое раньше не работало из-за залипшего кэша.
14 max735
 
20.12.17
00:59
(13) Есть такой момент: "кривые" номера берутся откуда-то отдаленно от текущих номеров. Сейчас подумалось, что тестовая база не обновлялась пару месяцев, и возможно проблема в том, что остаются косяки именно от старой тестовой копии...
15 Armando
 
20.12.17
01:54
(3) СП: "Выполняет обновление номеров в соответствии с номерами, записанными в базе данных. После вызова данного метода все выданные, но незаписанные номера, становятся невалидными т.к. не гарантируется их уникальность. Данный метод разрешено вызывать только администратору системы."

У нас штук 200 всяких тестовых баз. Минимум 10 раз в день выполняется копирование из продуктива в тестовые базы средствами СУБД.
Примерно раз в месяц кто-то ловит такую ошибку.
16 ИС-2
 
naïve
20.12.17
10:39
тоже есть такая ошибка. Лечится перенумерацией базы
17 FIXXXL
 
20.12.17
10:51
(9) скорее всего "поднимает" бэкап в подключенную базу скуля, которая, в свою очередь, подключена к серверу1С,
на сервере1С есть серверный кэш, в том числе и по нумерации, вот он может подкидывать подлянки при таком восстановлении
Проблемы невозможно решaть нa том же уровне компетентности, нa котором они возникaют. Альберт Эйнштейн