Потеря данных при загрузке измененной конфигурации
Доброго времени!
Первый раз за многолетний опыт столкнулся с такой ситуацией.
Несколько баз обновляются автоматически по ночам батником через загрузку измененной конфигурации.
Сегодня столкнулись с тем, что значения некоторых реквизитов очистились, причем по всем базам.
Картина при ручном моделировании загрузки вышла такая:
Причем если делать обычным сравнением/объединением, то различий метаданных в показанной части нет и данные не теряются.
Единственное что сделано было необычного перед обновлением - в дереве конфигурации отсортированы справочники и документы кнопкой "Отсортировать по алфавиту".
При повторной загрузке той же конфигурации такой картины уже нет, то есть ситуация уже не возникнет.
Подскажите пожалуйста, вследствие чего могла возникнуть такая ситуация и как избежать её в дальнейшем?,
Первый раз за многолетний опыт столкнулся с такой ситуацией.
Несколько баз обновляются автоматически по ночам батником через загрузку измененной конфигурации.
Сегодня столкнулись с тем, что значения некоторых реквизитов очистились, причем по всем базам.
Картина при ручном моделировании загрузки вышла такая:
Причем если делать обычным сравнением/объединением, то различий метаданных в показанной части нет и данные не теряются.
Единственное что сделано было необычного перед обновлением - в дереве конфигурации отсортированы справочники и документы кнопкой "Отсортировать по алфавиту".
При повторной загрузке той же конфигурации такой картины уже нет, то есть ситуация уже не возникнет.
Подскажите пожалуйста, вследствие чего могла возникнуть такая ситуация и как избежать её в дальнейшем?,
По теме из базы знаний
- Порядок обновления релизов конфигураций 7.7
- Технология обновления нетиповых конфигураций 1С:Предприятия 7.7
- Выгрузка-загрузка любых данных (и измененных) между похожими конфигурациями (ФАЙЛ, HTTP, COM) ЛЮБЫХ баз 1С 8.1-8.3 с обработкой и поиском данных по произвольным полям поиска
- Загрузка документов и номенклатуры из Excel в 1С "одним нажатием": УПД, ТОРГ-12, отчеты маркетплейсов, заказы, счета, прайсы
- Управление сборкой. Расширение для конфигурации СППР
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Такая ситуация возможна когда в новую конфигурацию(на которую необходимо обновиться) вручную добавили реквизиты, а не сравнением и объединением. Идентификаторы метаданных отличаются не смотря одинаковые наименования реквизитов. Ищите того кто-собирал релиз новой конфигурации, он добавил их вручную.
(18)
Разумеется, никакие способы обновления автоматически не разрулят конфликт разных идентификаторов реквизитов при их одинаковых наименованиях, тут я был неправ.
Теперь надо думать над тем - что дальше? Продолжит ли разработчик использование новых идентификаторов или "вернет" старые? Я бы дождался следующего обновления, сделал копию любой базы, вычистил бы из нее дубли и накатил обновление. А потом смотрел бы - что добавилось? "Старый" или "новый" реквизит? Если "старый" (вернулся) - то просто удалить пустышку "новый" и жить дальше. А если "новый", то это значит, что переход на "новые" произошел окончательно и надо скопировать в него содержимое таблиц "старого" (обработкой или средствами SQL) и тогда удалить ставший ненужным "старый" реквизит.
Хотя нет никаких гарантий, что однажды эта история не повторится в обратном порядке или с другими реквизитами.
Задвоившиеся реквизиты уже давно и в БД, и в цф-нике.
Видимо-таки какой-то баг.
Причем, случился он тоже давно. Только по каким-то причинам до сих пор не проявлял себя потерей данных.
Видимо-таки какой-то баг.
Разумеется, никакие способы обновления автоматически не разрулят конфликт разных идентификаторов реквизитов при их одинаковых наименованиях, тут я был неправ.
Теперь надо думать над тем - что дальше? Продолжит ли разработчик использование новых идентификаторов или "вернет" старые? Я бы дождался следующего обновления, сделал копию любой базы, вычистил бы из нее дубли и накатил обновление. А потом смотрел бы - что добавилось? "Старый" или "новый" реквизит? Если "старый" (вернулся) - то просто удалить пустышку "новый" и жить дальше. А если "новый", то это значит, что переход на "новые" произошел окончательно и надо скопировать в него содержимое таблиц "старого" (обработкой или средствами SQL) и тогда удалить ставший ненужным "старый" реквизит.
Хотя нет никаких гарантий, что однажды эта история не повторится в обратном порядке или с другими реквизитами.
(22) Видимо я неправильно выразился.
Под задвоившимися реквизитами я имел ввиду те реквизиты, которые разъехались по идентификаторам перед обновлением.
Но поскольку обновление выполнялось батником в автоматическом режиме, то дублей реквизитов не возникло, а старые реквизиты подменились "новыми" с измененными идентификаторами, отчего информация в БД в них пропала.
После обновления получается, что конфигурации БД и конфигурация обновления по идентификаторам теперь идентичны.
И в дальнейшем, если ничего подобного не случится, все будет обновляться нормально.
То есть мы волей-неволей остаемся на новых идентификаторах с последующим восстановлением потерянной информации.
Списывая этот случая на непонятный нам баг.
(22)
Угу, видимо так.
Под задвоившимися реквизитами я имел ввиду те реквизиты, которые разъехались по идентификаторам перед обновлением.
Но поскольку обновление выполнялось батником в автоматическом режиме, то дублей реквизитов не возникло, а старые реквизиты подменились "новыми" с измененными идентификаторами, отчего информация в БД в них пропала.
После обновления получается, что конфигурации БД и конфигурация обновления по идентификаторам теперь идентичны.
И в дальнейшем, если ничего подобного не случится, все будет обновляться нормально.
То есть мы волей-неволей остаемся на новых идентификаторах с последующим восстановлением потерянной информации.
Списывая этот случая на непонятный нам баг.
(22)
Хотя нет никаких гарантий, что однажды эта история не повторится в обратном порядке или с другими реквизитами
Угу, видимо так.
(1)
Можно попробовать выгружать конфигурацию в файлы. И сравнивать с предыдущей версией конфигурации(в файлах). .
Если изменённых файлов слишком много, то что-то пошло не так.
Или сравнивать один из файлов который точно не должен меняться.
как избежать её в дальнейшем?
Можно попробовать выгружать конфигурацию в файлы. И сравнивать с предыдущей версией конфигурации(в файлах). .
Если изменённых файлов слишком много, то что-то пошло не так.
Или сравнивать один из файлов который точно не должен меняться.
(2) Спасибо за отклик.
Правда, так и не понял, откуда пошло раздвоение, наверное на этот вопрос никто не ответит.
Поставил флаг.
Получил такое.
То есть раньше реквизит замещался с потерей данных.
Теперь дублируется под другим идентификатором.
Третьего не дано?
Правда, так и не понял, откуда пошло раздвоение, наверное на этот вопрос никто не ответит.
Поставил флаг.
Получил такое.
То есть раньше реквизит замещался с потерей данных.
Теперь дублируется под другим идентификатором.
Третьего не дано?
(5)
Один и тот же человек делает это из года в год.Как так получилось - неизвестно.
Он правильно установит "кривое" обновление?
Надо попробовать.
Разве что авторы кривого обновления.
Один и тот же человек делает это из года в год.Как так получилось - неизвестно.
Место для танцев с бубном так быстро не кончается, можно вместо BATника попробовать, например, "Обновлятор 1С"
Он правильно установит "кривое" обновление?
Надо попробовать.
Судя по скриншоту, "поехали" внутренние идентификаторы реквизитов. При загрузке измененной конфигурации реквизиты со старыми идентификаторами были признаны удаленными(вместе с данными, ессесно), с новыми добавились. Идентификаторы могут поехать от сортировки, ручного удаления/добавления, у меня как-то хранилище перекорёжило идентификаторы.... Как бы, ситуация с далеко не нулевой вероятностью при такой способе обновления.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот