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

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

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

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

Хотя нет никаких гарантий, что однажды эта история не повторится в обратном порядке или с другими реквизитами.
23. cargobird 306 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 306 25.04.18 15:17 Сейчас в теме
(2) Спасибо за отклик.
Правда, так и не понял, откуда пошло раздвоение, наверное на этот вопрос никто не ответит.
Поставил флаг.
Получил такое.
http://prntscr.com/j9x9vc
То есть раньше реквизит замещался с потерей данных.
Теперь дублируется под другим идентификатором.
Третьего не дано?
5. Cooler 22 25.04.18 15:23 Сейчас в теме
(3)
так и не понял, откуда пошло раздвоение, наверное на этот вопрос никто не ответит.
Разве что авторы кривого обновления.
Третьего не дано?
Место для танцев с бубном так быстро не кончается, можно вместо BATника попробовать, например, "Обновлятор 1С"
8. cargobird 306 25.04.18 15:37 Сейчас в теме
(5)
Разве что авторы кривого обновления.

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

Он правильно установит "кривое" обновление?
Надо попробовать.
4. cargobird 306 25.04.18 15:18 Сейчас в теме
(2) Отмечу еще раз, что это делается батником в автоматическом режиме. Никакие флаги кроме доступных консольных команд не изменить.
6. Healer 1 25.04.18 15:31 Сейчас в теме
Стандартная обработка "Обновление ИБ" после обновлений отрабатывала?
10. cargobird 306 25.04.18 15:39 Сейчас в теме
(6) Конфигурация нетиповая. Обновление - это просто измененный цф-ник. Тот Же самый, которым были обновлены базы в прошлый раз, только добавлены изменения. Так вот, те реквизиты, которые пропали - не изменялись.
7. Healer 1 25.04.18 15:32 Сейчас в теме
По моему опыту данные могут исчезать только при изменении типа реквизитов, и то не всегда.
9. cargobird 306 25.04.18 15:38 Сейчас в теме
(7) Один точно был булево и остался булево. Данные затерлись.
13. Healer 1 25.04.18 15:47 Сейчас в теме
14. cargobird 306 25.04.18 15:51 Сейчас в теме
16. Healer 1 25.04.18 16:06 Сейчас в теме
Я склоняюсь к мысли, что дело именно в БД. Попробуйте манипуляции, приводящие к исчезновению (обновления cf-ками), повторить в файловом варианте базы: подозреваю, что данные могут не исчезнуть.
19. cargobird 306 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 71 30.04.18 21:24 Сейчас в теме
(20) мне кажется Вы правы!
21. Lisenochek 26.04.18 10:11 Сейчас в теме
Можно попробовать попробовать принудительно установить соответствие в "сравнить, объединить", а после обновить с типом обновления из файла.
Оставьте свое сообщение
Вакансии
1С аналитик
Москва
зарплата от 210 000 руб.
Полный день

Руководитель направления 1С
Москва
зарплата от 350 000 руб.
Полный день

1С Программист
Москва
зарплата от 180 000 руб.
Полный день

Программист 1С
Москва
зарплата от 180 000 руб. до 220 000 руб.
Полный день

Аналитик 1С / Бизнес-аналитик
Нижний Новгород
зарплата от 100 000 руб. до 250 000 руб.
Временный (на проект)