Потеря данных при загрузке измененной конфигурации

1. cargobird 307 25.04.18 13:24 Сейчас в теме
Доброго времени!
Первый раз за многолетний опыт столкнулся с такой ситуацией.
Несколько баз обновляются автоматически по ночам батником через загрузку измененной конфигурации.
Сегодня столкнулись с тем, что значения некоторых реквизитов очистились, причем по всем базам.
Картина при ручном моделировании загрузки вышла такая:
http://prntscr.com/j9vbdy
Причем если делать обычным сравнением/объединением, то различий метаданных в показанной части нет и данные не теряются.
Единственное что сделано было необычного перед обновлением - в дереве конфигурации отсортированы справочники и документы кнопкой "Отсортировать по алфавиту".
При повторной загрузке той же конфигурации такой картины уже нет, то есть ситуация уже не возникнет.
Подскажите пожалуйста, вследствие чего могла возникнуть такая ситуация и как избежать её в дальнейшем?,
По теме из базы знаний
Вознаграждение за ответ
Показать полностью
Ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
11. solodovnikov.84 11 25.04.18 15:42 Сейчас в теме
(1)а платформы различаются там где обновляете и где это обновление ставиться?
12. cargobird 307 25.04.18 15:44 Сейчас в теме
15. Kaval88 173 25.04.18 15:55 Сейчас в теме
(1) Такая ситуация возможна когда в новую конфигурацию(на которую необходимо обновиться) вручную добавили реквизиты, а не сравнением и объединением. Идентификаторы метаданных отличаются не смотря одинаковые наименования реквизитов. Ищите того кто-собирал релиз новой конфигурации, он добавил их вручную.
18. cargobird 307 26.04.18 07:19 Сейчас в теме
(15) Двадцать пять БД на одной и той же конфигурации. Ситуация повторилась во всех.
Задвоившиеся реквизиты уже давно и в БД, и в цф-нике.
Видимо-таки какой-то баг.
22. Cooler 22 26.04.18 10:37 Сейчас в теме
(18)
Задвоившиеся реквизиты уже давно и в БД, и в цф-нике.
Видимо-таки какой-то баг.
Причем, случился он тоже давно. Только по каким-то причинам до сих пор не проявлял себя потерей данных.

Разумеется, никакие способы обновления автоматически не разрулят конфликт разных идентификаторов реквизитов при их одинаковых наименованиях, тут я был неправ.

Теперь надо думать над тем - что дальше? Продолжит ли разработчик использование новых идентификаторов или "вернет" старые? Я бы дождался следующего обновления, сделал копию любой базы, вычистил бы из нее дубли и накатил обновление. А потом смотрел бы - что добавилось? "Старый" или "новый" реквизит? Если "старый" (вернулся) - то просто удалить пустышку "новый" и жить дальше. А если "новый", то это значит, что переход на "новые" произошел окончательно и надо скопировать в него содержимое таблиц "старого" (обработкой или средствами SQL) и тогда удалить ставший ненужным "старый" реквизит.

Хотя нет никаких гарантий, что однажды эта история не повторится в обратном порядке или с другими реквизитами.
23. cargobird 307 26.04.18 13:17 Сейчас в теме
(22) Видимо я неправильно выразился.
Под задвоившимися реквизитами я имел ввиду те реквизиты, которые разъехались по идентификаторам перед обновлением.

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

После обновления получается, что конфигурации БД и конфигурация обновления по идентификаторам теперь идентичны.

И в дальнейшем, если ничего подобного не случится, все будет обновляться нормально.

То есть мы волей-неволей остаемся на новых идентификаторах с последующим восстановлением потерянной информации.
Списывая этот случая на непонятный нам баг.

(22)
Хотя нет никаких гарантий, что однажды эта история не повторится в обратном порядке или с другими реквизитами

Угу, видимо так.
24. user625969_Skreg2016 28.04.18 13:21 Сейчас в теме
(1)
как избежать её в дальнейшем?

Можно попробовать выгружать конфигурацию в файлы. И сравнивать с предыдущей версией конфигурации(в файлах). .
Если изменённых файлов слишком много, то что-то пошло не так.

Или сравнивать один из файлов который точно не должен меняться.
2. AnryMc 849 25.04.18 14:07 Сейчас в теме
А так?
Прикрепленные файлы:
3. cargobird 307 25.04.18 15:17 Сейчас в теме
(2) Спасибо за отклик.
Правда, так и не понял, откуда пошло раздвоение, наверное на этот вопрос никто не ответит.
Поставил флаг.
Получил такое.
http://prntscr.com/j9x9vc
То есть раньше реквизит замещался с потерей данных.
Теперь дублируется под другим идентификатором.
Третьего не дано?
5. Cooler 22 25.04.18 15:23 Сейчас в теме
(3)
так и не понял, откуда пошло раздвоение, наверное на этот вопрос никто не ответит.
Разве что авторы кривого обновления.
Третьего не дано?
Место для танцев с бубном так быстро не кончается, можно вместо BATника попробовать, например, "Обновлятор 1С"
8. cargobird 307 25.04.18 15:37 Сейчас в теме
(5)
Разве что авторы кривого обновления.

Один и тот же человек делает это из года в год.Как так получилось - неизвестно.
Место для танцев с бубном так быстро не кончается, можно вместо BATника попробовать, например, "Обновлятор 1С"

Он правильно установит "кривое" обновление?
Надо попробовать.
4. cargobird 307 25.04.18 15:18 Сейчас в теме
(2) Отмечу еще раз, что это делается батником в автоматическом режиме. Никакие флаги кроме доступных консольных команд не изменить.
6. Healer 1 25.04.18 15:31 Сейчас в теме
Стандартная обработка "Обновление ИБ" после обновлений отрабатывала?
10. cargobird 307 25.04.18 15:39 Сейчас в теме
(6) Конфигурация нетиповая. Обновление - это просто измененный цф-ник. Тот Же самый, которым были обновлены базы в прошлый раз, только добавлены изменения. Так вот, те реквизиты, которые пропали - не изменялись.
7. Healer 1 25.04.18 15:32 Сейчас в теме
По моему опыту данные могут исчезать только при изменении типа реквизитов, и то не всегда.
9. cargobird 307 25.04.18 15:38 Сейчас в теме
(7) Один точно был булево и остался булево. Данные затерлись.
13. Healer 1 25.04.18 15:47 Сейчас в теме
14. cargobird 307 25.04.18 15:51 Сейчас в теме
16. Healer 1 25.04.18 16:06 Сейчас в теме
Я склоняюсь к мысли, что дело именно в БД. Попробуйте манипуляции, приводящие к исчезновению (обновления cf-ками), повторить в файловом варианте базы: подозреваю, что данные могут не исчезнуть.
19. cargobird 307 26.04.18 07:20 Сейчас в теме
(16) БД двадцать пять штук, везде одно и тоже.
Может в самой базе, в которой формируется цф-ник для обновления баг.
17. Healer 1 25.04.18 16:07 Сейчас в теме
Если данные не исчезнут, надо будет внимательно посмотреть, что там такое случается в MS SQL :-)
20. catena 110 26.04.18 08:05 Сейчас в теме
Судя по скриншоту, "поехали" внутренние идентификаторы реквизитов. При загрузке измененной конфигурации реквизиты со старыми идентификаторами были признаны удаленными(вместе с данными, ессесно), с новыми добавились. Идентификаторы могут поехать от сортировки, ручного удаления/добавления, у меня как-то хранилище перекорёжило идентификаторы.... Как бы, ситуация с далеко не нулевой вероятностью при такой способе обновления.
25. johnnyshut23 74 30.04.18 21:24 Сейчас в теме
(20) мне кажется Вы правы!
21. Lisenochek 26.04.18 10:11 Сейчас в теме
Можно попробовать попробовать принудительно установить соответствие в "сравнить, объединить", а после обновить с типом обновления из файла.
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот