А по-моему, они одинаковые

Сравнение конфигураций показывает, что они одинаковые, когда на самом деле код или прикладные объекты различаются. Кто виноват и что с этим делать?
Статья обновлена и дополнена.

«Стою на асфальте я в лыжи обутый…» Именно эта фраза крутилась у меня в голове на второй час ковыряния в базе одного из клиентов.

Суть истории такая: есть копия production базы клиента (развернутая в файловом варианте dt выгрузка с боевого сервера) и есть CF из test base с изменёнными объектами. При сравнении рабочей конфигурации с CF платформа пишет, что они идентичные, хотя открытие одного и того же модуля прямо из окна сравнения визуально показывает, что они различаются.

Коллега, принесший сие «чудо» утверждает, что «полтергейст» начался где-то с полмесяца назад, когда при накате изменений на рабочую базу упал сервер 1С. Базу из резервной восстанавливать не стали, т.к. после перезапуска она была вполне работоспособной и все проверки показали адекватное поведение.

Паранормальные явления начались спустя неделю после нескольких обновлений. У пользователей после проведения обновления объекты не менялись.

Сначала грешили на кэш. Путаницы добавило, что после чистки кэша действительно часть проблем ушла.

Помогало также ручное принудительное обновление объектов (т.е. прямо в рабочей базе), но назвать это панацеей можно было с трудом.

Итак, после того, как эта база попала наконец ко мне в руки, она была подвергнута все видам пыток тестирований, какие только можно было придумать (ТиИ, chdbfl, выгрузка/загрузка dt, выгрузка/загрузка cf, всевозможные манипуляции с Config и ConfigSave в SQL и т.п.). Не помогало ничего. Frown

Здесь моя статья разделится на две части:

  1. Моё изначальное предположение (дабы сохранить смысл последовавших комментариев)
  2. Разъяснение уважаемого awa, давшего техническое понимание ситуации

1. Предположение

Вспомнилось, что ещё в 8.2 в одном из релизов разработчиками декларировалось существенное увеличение производительности при операции сравнения конфигураций, в этом же релизе требовалась конвертация конфигурации для совместимости. Производительность сравнения действительно повысилась в разы, что уже тогда наталкивало на мысль на внедрении контрольных чисел (или хэшей) в структуру метаданных. Совместив эту информацию с поведением базы при ручном изменении объектов был сделан утвердительный вывод о присутствии и использовании неких контрольных величин (предположительно хэшей) в метаданных. Т.е. сравнение непосредственно самих объектов производилось исключительно при несовпадении сохраненных контрольных значений. Если же значения совпадали платформа априори считала, что объекты идентичны и необходимости в более подробном сравнении нет. Осталось только придумать способ групповой переинициализации хэшей для всех объектов, т.к. ручной способ «по одному объекту» для конфигурации на базе УТ11 был совершенно неприемлем.

И тут вспомнился один механизм платформы, который я практически никогда не применял в своей практике, тем не менее как нельзя кстати подходящий для данной ситуации. Речь идет о возможности выгрузить/загрузить объекты конфигурации в отдельные файлы (меню «Конфигурация», пункты «Выгрузить конфигурацию в файлы…» и «Загрузить конфигурацию из файлов…»

Что в этом случае должно произойти? Выгружаются все объекты, включая формы, во внешние файлы, но в отличие от выгрузки в бинарном формате CF, выгружается не слепок конфигурации, а описание объектов в декларативном виде. Т.к. данный механизм как раз и предназначался для внесения изменений в эти файлы для последующей загрузки, то хэш объекта не выгружается, а при загрузке обратно рассчитывается заново.

Итак, возвращаясь к исходной истории, могу сказать, что после проведения вышеописанной процедуры выявилось расхождение по целому ряду объектов. Устранив данные расхождения, мы добились полного восстановления работоспособности базы.

2. На самом деле


Комментарий (24) от awa:

В конфигурации есть файлик versions, который хранит версии всех объектов конфигурации (а если точнее, то не объектов, а файлов, в которых хранятся объекты). Версия каждого файла — это просто GUID. При каждом изменении объекта просто генерится новый случайный GUID.  

При сравнении конфигураций 1С сначала сравнивает версии файлов, и если они равны, не делает дальнейшего сравнения. Если же версии не равны, то сравниваются между собой непосредственно файлы объектов. При этом нужно еще учитывать, что метаданные хранятся в конфигурации иерархически, в виде дерева. Поэтому, даже если версии двух конкретных файлов не равны, но версии файлов-родителей равны, то сравнение просто не дойдет до сравнения этих файлов, так как «обрубится» на сравнении родителей.


Как видите, с «техникой» я немного не угадал, но по сути был довольно близок. Только роль контрольных сравниваемых значений здесь играет не предположительная хэш-функция, а сгенерированный в процессе модификации объекта GUID. Тем не менее, предложенный (по наитию) способ исправления сохранил свою актуальность.

Советую прочитать комментарий полностью, т.к. помимо пояснения там ещё предложен альтернативный способ исправления. И если пожелаете поставить плюс данной статье, не забудьте поставить плюс и этому комментарию.

Кстати, упомянутые ошибки в механизме выгрузки/загрузки через файлы действительно имеют место быть, но преимущественно связаны с НФ-режимом конфигурации, т.к. часто некорректно выгружались именно формы с объектными ссылками, в УФ-режиме явных проблем я не наблюдал, т.к. управляемые формы довольно хорошо сериализируются. Тем не менее, соглашусь, что данный метод Вы применяете на свой страх и риск (впрочем, как и само использование продуктов 1С 🙂 ).

Желаю Вам не попадать в такие ситуации, но если уж попали, то вот вам на вооружение инструкция, как из неё выходить.

P.S. Буквально спустя дня два в точно такую же ситуацию попал другой мой коллега, причём конфигурация была другая (БП 3.0) и релиз платформы был из последних на тот момент. Так что ни от конфигурации, ни от версии платформы это не зависит (по крайней мере пока).

65 Comments

  1. TODD22
    Коллега, принесший сие «чудо» утверждает, что «полтергейст» начался где-то с полмесяца назад, когда при накате изменений на рабочую базу упал сервер 1С. Базу из резервной восстанавливать не стали, т.к. после перезапуска она была вполне работоспособной и все проверки показали адекватное поведение.

    Того кто решил работать в базе после падения при обновлении уже уволили? Ну или хотя бы премии лишили?

    Reply
  2. mbreaker

    (1) TODD22, если бы 1С увольнял сотрудников после каждого допущенного бага, в Москве не осталось бы программистов, не поработавших в 1С. 🙂

    Reply
  3. TODD22

    (2) А при чём 1С и допущенные ошибки? Вам сотрудник фирмы 1С делал обновление и после падения в процессе обновления определил что база «вполне» работоспособна и решил на ней работать?

    Это не ошибка. Это некомпетентность сотрудника. В момент обновления производится реструктуризация таблиц если этот процесс завершился не корректно(выключением питания, падением сервера и тд) то какое может быть продолжение работы на этой базе?

    Reply
  4. bpc222

    (2)

    :))) ничего… есть еще «другая Россия»… регионы поддержат

    Reply
  5. mbreaker

    (3) TODD22, я согласен, что выговора и ликбеза сотрудник достоин, но увольнение — это крайний радикализм (отсюда и шуточный пример с 1С). А для лишения премии должно быть достаточно веское основание, например прямой ущерб или убыток клиента. До этого — только превентивные меры (исключение можно сделать только для рецидива).

    Reply
  6. AlX0id

    Новый вид удара в бубен добавлен в evernote, спасибо )

    Reply
  7. Sanario

    Ладно вам. Типа сами так не попадали ни разу вообще:) Автору огромное спасибо. Статьей навел на кое-какие мысли

    Reply
  8. AlexO

    (7) Sanario,

    Статьей навел на кое-какие мысли

    На какие? У меня ничего, кроме «1С снова запуталась в трех соснах», не навела.

    Reply
  9. AlexO

    (0)

    К сожалению я не могу объяснить причину и технологическую подоплеку возникновения такой ситуации. Для меня тоже остается загадкой, как может так произойти, что объект меняется, а хеш не пересчитывается.

    какой «хэш» и чего не пересчитывается?

    Reply
  10. TODD22

    (7) Sanario,

    Ладно вам. Типа сами так не попадали ни разу вообще:)

    Ну как бы если падает 1Ска во время обновления или ТиИ из за отключения сервера, питания, кончилась память, посыпался винт и тд. То это повод поднять базу из бэкапа и повторить процесс до тех пор пока не получится. А если у тебя упал сервер в момент обновления. Ты проверил что база «вполне» работоспособна. А потом вылезли какие то проблемы то надо наверное надавать по рукам такому человеку и работать с базами данных запретить до тех пор пока не выучит мат. часть и не научиться делать правильно.

    Reply
  11. AlexO

    (11) TODD22,

    А если у тебя упал сервер в момент обновления.

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

    А если у тебя упал сервер в момент обновления.

    это повод не только базу восстановить, но и сервер переустановить — кто его знает, что там с этими его кэшами и прочим хламом…

    Reply
  12. TODD22

    (12) AlexO,

    это повод не только базу восстановить, но и сервер переустановить — кто его знает, что там с этими его кэшами и прочим хламом…

    Это уже на усмотрение…. из за чего упало и тд.

    нужно всегда перед обновлением делать бэкап

    Разумеется нужно. Разговор не о бэкапах. А о том что если случилась такая проблема то нужно поднять из бэкапа и повторить операцию. А не махнуть рукой типа «вроде работает».

    Reply
  13. AlexO

    (13) TODD22,

    А не махнуть рукой типа «вроде работает».

    Никогда не воспринимал доводы «ну, это же коммерческая система, мы же знаем, как работают коммеречские системы…» Да, коммерческая.

    Но — российская коммерческая, со всеми сопутствующими.

    Reply
  14. Rustig

    (0) не пробовали снять с поддержки, а потом сравнить-объединить с постановкой на поддержку?

    Reply
  15. TODD22

    (15) Rustig,

    не пробовали снять с поддержки

    Может включить режим редактирования конфигурации?

    Reply
  16. mbreaker

    (7) Sanario, пожалуйста, подумать тем кто в теме действительно есть о чём.

    (8) AlexO,

    А автор не пробовал покопать в сторону трех видов конфигураций

    Дружище, прописные истины уровня дошколят в этой статье я не стал писать. И на всякий случай продекларирую заранее наличие у себя «1С:Эксперта по тех. вопросам» и шесть 1С:Специалистов, а также опыт руководства проектами высоконагруженных >100 польз. систем, во избежание будущих посягательств на степень своей компетенции.

    (10) AlexO,

    какой «хэш» и чего не пересчитывается?

    хэшем здесь я называю некое абстрактное контрольное число/знаконабор, которое предположительно храниться в структуре метаданных для ускорения процедуры сравнения. Советую почитать про хэш-функции и их применение. Полезно.

    (9) AlexO,

    На какие? У меня ничего, кроме «1С снова запуталась в трех соснах», не навела.

    Так значит есть куда расти: много читать, чаще думать, больше размышлять. Развиваться одним словом.

    Reply
  17. mbreaker

    (12) AlexO, (13) TODD22, чувствуется мнение людей, не работавших с высоконагруженными системами. С таким подходом можно и работу предприятия остановить, если по каждому чиху серверы переустанавливать, да базы (весом в несколько десятков гектар) из бэкапов поднимать. Для таких тяжёлых действий должны быть весомые обстоятельства, а не «жахну ка на всякий пожарный, мало ли».

    Этим комментарием я нисколько не умаляю необходимость резервного копирования. Просто всему должна быть мера и обоснование.

    Reply
  18. mbreaker

    (16) TODD22, коллега, не дискредитируйте себя окончательно. Во-первых, это совершенно разные механизмы, а во вторых, я в самом начале статьи написал, что в систему вносились «изменения», а не «обновления». Т.е. в системе уже были включены изменения. Проблема возникла при переносе доработок из draft-базы в production.

    (15) Rustig, снятие с поддержки всего лишь «убивает» конфигурацию поставщика, не затрагивая рабочую конфигурацию, а проблема была именно в рабочей. При постановке обратно максимум, что произойдёт — это переопределятся идентификаторы объектов метаданных. Поэтому целесообразности в этом действии я не вижу. Разве что с изменением идентификатора сработает триггер на пересчёт хэша объекта.

    Reply
  19. AlexO

    (17)

    хэшем здесь я называю некое абстрактное контрольное число/знаконабор, которое предположительно храниться в структуре метаданных для ускорения процедуры сравнения.

    а ничего так, что, несмотря на «наличие у себя «1С:Эксперта по тех. вопросам» и шесть 1С:Специалистов, а также опыт руководства проектами» — 1С продолжает сравнивать объекты по именам и ID?

    Reply
  20. AlexO

    (19)

    снятие с поддержки всего лишь «убивает» конфигурацию поставщика

    ну и, как «1С:Эксперта по тех. вопросам» и шесть 1С:Специалистов» — сколько еще конфигураций остается?

    Разве что с изменением идентификатора сработает триггер на пересчёт хэша объекта.

    как «1С:Эксперта по тех. вопросам» и шесть 1С:Специалистов» — где у 1С есть упоминание о магическом хэше?

    Reply
  21. TODD22

    (18) Работаем… и базы у нас по несколько десятков гектар. И пользователей много и работают 24 часа в сутки.

    Нужно правильно свою работу выполнять. А не по колхозному…. упало с ошибкой… да фигня…

    Для таких тяжёлых действий должны быть весомые обстоятельства, а не «жахну ка на всякий пожарный, мало ли».

    Падение сервера в момент реструктуризации базы это не «весомые обстоятельства»? ну..ну…(может её и не было. может конечно только код правили).

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

    С вашим подходом можно базу данных сломать. И потом писать статьи на ИС о том как вы их чините….

    То что вы нашли способ решения проблемы это замечательно, себе метод возьму на заметку. Теперь ещё научиться бы себе проблемы не создавать 😉

    что в систему вносились «изменения», а не «обновления».

    Реструктуризация таблиц была? Или только код добавили? Изменения/обновления какая разница. Процесс то один и тот же, или нет?

    коллега, не дискредитируйте себя окончательно.

    Чем же я себя дискредитировал?

    Reply
  22. AlexO

    (19) и еще, как у «»1С:Эксперта по тех. вопросам» и шесть 1С:Специалистов» — мне интересно, каким образом из магического хэша 1С так восстанавливала данные, что они отображались отличающимся кодом от сравниваемого CF?

    Reply
  23. awa

    Вот уж не думал, что многие не знают про то, как в 1С происходит сравнение конфигураций.

    В конфигурации есть файлик versions, который хранит версии всех объектов конфигурации (а если точнее, то не объектов, а файлов, в которых хранятся объекты). Версия каждого файла — это просто GUID. При каждом изменении объекта просто генерится новый случайный GUID. И это не хэш. Хэш-функция выдает один и тот же результат на одних и тех же входных данных.

    При сравнении конфигураций 1С сначала сравнивает версии файлов, и если они равны, не делает дальнейшего сравнения. Если же версии не равны, то сравниваются между собой непосредственно файлы объектов. При этом нужно еще учитывать, что метаданные хранятся в конфигурации иерархически, в виде дерева. Поэтому, даже если версии двух конкретных файлов не равны, но версии файлов-родителей равны, то сравнение просто не дойдет до сравнения этих файлов, так как «обрубится» на сравнении родителей.

    Конечно, в нормальной ситуации такое невозможно. Но в случае, описанном автором, при обновлении, похоже, успели записаться все измененные файлы конфигурации, но не успел записаться файл versions в таблице CONFIG. В результате и получилось, что некоторые объекты конфигурации были изменены, но версии их файлов остались старые. Кстати, механизм локального кэширования конфигурации использует те же самые GUID’ы-версии. Неудивительно, что у некоторых пользователей локальный кэш не менялся, так как сравнение версий показывало, что обновление в кэше не требуется.

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

    Можно также попробовать разобрать файл конфигурации с помощью v8Unpack, обрезать там содержимое файла versions до «{1,0}» и собрать с помощью v8Unpack конфигурацию обратно. Таким образом мы удалим все версии файлов. Затем эту конфигурацию надо загрузить в чистую базу и снова выгрузить. При этом 1С создаст заново версии файлов. Но этот способ нестандартный, только на крайний случай, я не советую им пользоваться, если можно обойтись без него.

    Reply
  24. mbreaker

    (14) AlexO, не смешите мои тапочки, коллега. Так может говорить только человек, всерьёз не сталкивавшийся с «крутыми иностранными коммерческими системами».

    Вы сначала познакомьтесь с этими системами не по брошюркам и презентациям, а в реалиях бизнес действительности.

    Нет «идеальных» систем. Есть системы более или менее подходящие в той или иной ситуации.

    Тот же Oracle (Database) имеет свои детские болезни (до сих пор полноценно так и не научился поддерживать синтаксис ANSI SQL 92 и хорошенько лагает при построении плана запроса на элементарных join’ах), а SAP (ERP) куда сложнее в развертывании на российских предприятиях (адаптация к законодательству хромает), чем тот же УПП. Но это нисколько не умаляет их преимуществ: масштабируемость и функциональность.

    Идеальность этих систем — это распространенный миф. Такой же, как и мнение о том, что автомобили BMW или Audi не ломаются.

    Reply
  25. AlexO

    (26)

    Тот же Oracle (Database) имеет свои детские болезни

    имеет, кто спорит. Но также имеет такой функционал, как корректное закрытие всех системных процессов базы в случае краша. До которого 1С как до Марса.

    (до сих пор полноценно так и не научился поддерживать синтаксис ANSI SQL 92

    а вот это уж точно не «детская болезнь» — MS SQL тоже не во всем поддерживает стандарт T-SQL, однако это не мешает быть MS лидером СУБД.

    Не говоря уже про Оракл.

    Reply
  26. AlexO

    (24) awa,

    Версия каждого файла — это просто GUID

    1С точно пользуется именно GUID?

    Reply
  27. mbreaker

    (22) TODD22, коллега, под дискредитацией я подразумевал подмену терминов «снять с поддержки» и «включить изменения». И не более. Так что передёргивать не стоит. Если это была шутка или неудачная фраза — просто так и скажите. У меня не было цели оскорбить.

    (20)(21)(23)(25) AlexO, уважаемый, прекратите нести чушь. Мало того, что в этом бреде я уже перестал понимать, что Вы хотите сказать, так Вы ещё немного и уже на личные оскорбления перейдёте. Выключите, пожалуйста, режим односложного неконструктива. Свои сертификаты я привёл не ради бахвальства, а чисто для исключения из комментариев советов типа «а с той ли конфигурацией ты сравнивал?».

    Reply
  28. awa

    (29) Простите, Вы очень похожи на тролля, от Вас всегда идет очень много вопросов, по делу и не очень. Я сказал, что хотел. Ваше право верить или не верить, проверить или забить.

    Reply
  29. AlexO

    (22) TODD22,

    То что вы нашли способ решения проблемы это замечательно

    не знаю, что нашел коллега, но не пробовал ли он хотя бы жестко накатить нормальный CF на ломанную базу?

    В этом случае 1С должна была принудительно обновить объекты и версии ID, что снимает проблему, поднятую AWA.

    Reply
  30. mbreaker

    (24) awa, Валерий, ну не все из нас «жёлтых» на досуге балуются написанием Tool_1CD и ковырянием 1CD в «сыром» виде. 🙂

    Большой РЕСПЕКТ Вам, кстати замечательный инструмент.

    Вот уж не думал, что многие не знают про то, как в 1С происходит сравнение конфигураций.

    Данная фраза подразумевает наличие какого-то интересного ресурса (статьи/документации/проч.), описывающего данный процесс?

    Я такой, к сожалению, не нашёл. Поделитесь, буду премного благодарен!

    (28) AlexO, сарказм — вещь здоровая, но в данном случае неуместная, я в статье напрямую говорю о том, что технологическое описание — это всего лишь моё предположение, а статья написана в стиле рассуждения, а не постулата.

    Reply
  31. mbreaker

    (32) AlexO, превозмогая нарастающую антипатию к Вам, всё же отвечу: это всё перепробовал ещё до меня тот мой коллега — не помогло. Все высказанные Вами предложения были проверены моим коллегой ещё до обращения ко мне. Кстати, для справки: «1С:Эксперт» — это компетенция высокоуровневого оптимизатора и корректора, а не низкоуровневого «механика». И под «высоким» и «низким» уровнем я подразумеваю рабочую среду, а не компетенции, т.к. на «низком» уровне зачастую работать куда сложнее и знаний требуется больше.

    (31) awa, всецело поддерживаю.

    (33) AlexO, а вот уже и оскорбления пошли в ход.

    Reply
  32. Puk2

    (3) TODD22,

    В момент обновления производится реструктуризация таблиц если этот процесс завершился не корректно(выключением питания, падением сервера и тд) то какое может быть продолжение работы на этой базе?

    Насколько я помню ещё с 8.1 обновление происходит в транзакции, точнее несколькими транзакциями. При реструктуризации создаются копии изменяемых таблиц (размер базы во время обновления может увеличиваться до 2 раз). Если в транзакции совершаются ошибки, то реструктуризация не применяется к рабочим таблицам. У платформы есть штатные механизмы защиты от сбоев, за знание которых не всегда требуется увольнять сотрудников.

    Reply
  33. webester

    (34) awa правильно говорит, AlexO троллит и язвит всегда и везде, где только есть хоть какая то возможность показать свою значимость. Пользы от его ответов обычно 0. Те кто давно здесь уже привыкли и не обращают внимания например как в (31), те кто не так давно пытаются спорить

    Reply
  34. mbreaker

    (37) webester,

    AlexO троллит и язвит всегда и везде, где только есть хоть какая то возможность показать свою значимость

    Была бы хоть какая-то значимость… а то пустой трёп ни о чём…

    Я на IS урывками, последнее время работа не позволяет много времени уделять данному проекту, поэтому последних новостей по имеющимся в системе троллям — не знаю…

    А за совет — спасибо. Учту. 🙂

    Reply
  35. awa

    (34) Нет, сходу вспомнить никакой ссылки не смогу. Может я не прав, но мне действительно казалось это довольно известным и очевидным. v8Unpack существует много лет. Есть и другие инструменты просмотра конфигураций «изнутри». С их помощью очень легко увидеть внутреннее содержимое. А файл versions имеет говорящее название и очень простое содержимое: в нем записаны пары <Имя файла> — <Версия>.

    Reply
  36. AlexO

    (39) awa,

    А файл versions имеет говорящее название и очень простое содержимое: в нем записаны пары <Имя файла> — <Версия>.

    И? К ответу на воопросы в 28 так и не пришли, предпочьтя с mbreaker и разными webester обсуждать совсем другие интересы.

    (36) Puk2,

    Насколько я помню ещё с 8.1 обновление происходит в транзакции, точнее несколькими транзакциями.

    А если выключается электричество — какие защиты в 1С сработают? Никакие. В 1С нет такой защиты.

    Reply
  37. mbreaker

    (39) awa, это, кстати, распространённое заблуждение признанных гуру. Им некоторые совершенно необъективные вещи кажутся обыденно элементарными.

    Все мы таким болеем. Нужно стараться абстрагироваться от осознания своего багажа знаний, чтобы передавать эти знания прочим людям.

    Кстати, можно назвать это «синдромом Холмса»… Это элементарно, Ватсон! 🙂

    Reply
  38. mbreaker

    (24) awa, кстати, один из вариантов более безопасного восстановления БД — это моим способом восстановить подопытную ИБ, затем выгрузить исправленный CF, и на production базе сделать уже «управляемое» сравнение/объединение, оставив к объединению только те объекты, которые действительно нуждаются в исправлении. Такой способ убережёт от нежелательных модификаций базы. Как показал опыт, количество «разъехавшихся» объектов не так уж велико, чтобы не потратить лишние 5-10 минут для их ревизии.

    Reply
  39. Armando

    С описанной проблемой сталкивались при динамическом обновлении. Исправляли несущественным изменением объекта, и повторным обновлением. На партнерском проблема несколько раз поднималась. От представителей 1С еще давно был ответ, что они в курсе такого поведения платформы, но что с этим делать не знают.

    Reply
  40. awa

    (42) никто и не спорит. В реальности ситуации бывают очень разными. Тут главное, имхо, как можно лучше понимать, как что устроено, что от чего зависит и на что влияет. И в каждый конкретной ситуации выбирать тот или иной способ. Универсальных решений не существует. И правильных путей всегда много. Надо найти хоть один, основываясь на своих и чужих знаниях и опыте и на здравом смысле)) В моей практике восстановления баз и конфигураций какие только способы не приходилось придумывать.

    Сорри за такой неконкретный и размытый ответ на грани оффтопа.

    Reply
  41. mbreaker

    (44) awa, извиняться абсолютно не за что, готов подписаться под каждым словом в данном ответе. Иногда в поисках «правильного пути» шаманские пляски с бубном кажутся более логичными, чем очередной эксперимент с базой, приводящий к желаемому результату. Главное — в последствие понять природу и принцип свершенного действия. В данной статье, благодаря Вашему комментарию, я своей цели добился, а заодно и другим открыл этот секрет. А о том, что далеко не для всех это настолько очевидно, как Вы себе представляли, говорит растущий рейтинг этой статьи (а также Вашего комментария) и список тех, кто поставил плюс (там не только «новички», а также много весьма уважаемых мною профессионалов своего дела).

    Reply
  42. kapustinag

    (43) Armando, С этой-то проблемой справиться — невелика премудрость. Я имею в виду — с проблемой несоответствия реальной версии объекта и номера его версии, хранящегося в файле Vesions. Нужно просто хранить номер версии не только в файле Versions, но и в самом объекте. Тогда, если объект запишется успешно, а Versions — не успеют, нестыковка номеров версий будет легко обнаружена.

    Может быть, этот лежащий на поверхности способ имеет какие-то недостатки и/или побочные эффекты, из-за которых он не подошел разработчикам платформы.

    (0), Интересно было почитать и статью, и обсуждение. Спасибо.

    Reply
  43. LexSeIch

    Мир этому дому!

    Для большинства пользователей платформа 1С — Большой «Черный ящик» и понимание каких то внутренних механизмов его строения и функционирования приходят не сразу, а чаще в тех случаях, когда сталкиваешься с какой-то проблемой … Статья отличная — автор показывает как на интуитивном уровне возникает предположение о возможных механизмах работы системы и косвенно получает подтверждение правильности своих выводов. То что в комментариях дается дополнительная информация по сравнению конфигураций — еще один плюс публикации. Кому то может помочь и конкретное решение (так как оно помогло автору).

    Reply
  44. AlexO

    (42) (44) awa, ребята, вы совсем не то обсуждаете.

    Нужен конкретный рабочий способ.

    А не танцы — может, получится, может — нет.

    А уж это — «Как показал опыт, количество «разъехавшихся» объектов» — да оно может быть каким угодно, это количество.

    В общем, пока воз и ныне там.

    (46) kapustinag, в том и дело, что проблема не решена, причем опять уперлись в 1С-ограничения.

    Reply
  45. AlexO

    (44) awa,

    Универсальных решений не существует.

    Существуют.

    Например, разработчик сразу закладывает в продукт механизм самовосстановления/проверки тех же версий.

    Вот как с индексами сделано в СУБД (не в 1С, конечно).

    Reply
  46. mbreaker

    (48) AlexO,

    Нужен конкретный рабочий способ.

    Ага, один на все жизненные случаи. Удачи в поисках.

    (49) AlexO,

    Например, разработчик сразу закладывает в продукт механизм самовосстановления/проверки тех же версий.

    Чёрт, ну как же я сам-то не догадался! Надо было сразу к Сергею Нуралиеву идти с этой гениальной идеей!!! Позор на мои седины! Вот же оно решение! На поверхности лежало! Всего-то и нужно было: ногой распахнуть дверь в новом офисе 1С на Дмитровском, найти этих недоразвитых разработчиков и сказать «щас, имбецилы, я вас правильно писать программы научу!». Признаю свой промах и по праву предоставляю честь сделать это Вам лично, AlexO.

    Reply
  47. mbreaker

    (49) AlexO, слушай, извини за всплеск эмоций, но ты реально умеешь «подогреть» на подобные ответы.

    Прости за нескромный вопрос, сколько тебе лет?

    Reply
  48. Бурухтан Второй Второй

    А кто может объяснить мне обратную ситуацию? Например в БП при обновлении конфы в сравнении и объединении постоянно указана обработка ПечатьТТН как измененная в основной конфе (рабочей). Хотя я её не менял. Более того — даже пару раз специально объединял с конфой поставщика — все равно при новом обновлении помечает её как измененную (а именно привязки на форме).

    Reply
  49. Lama12-1

    ТС. Спасибо за статью. Теперь понятно почему у меня сравнение конфигурации поставщика и основной конфигурации дает различия, даже если объект на поддержке и версии конфигураций совпадают.

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

    Т.е. версия объекта в конфигурации поставщика одна, а версия этого-же объекта в основной конфигурации другая?

    Кстати, видимо ситуация аналогична (52).

    Reply
  50. Патриот

    (0) и (24) +, спасибо за интересную инфу.

    (0) у нас месяц назад возникла похожая проблема, решил я её так:

    Создал новую пустую базу и загрузил туда конфу проблемной базы до обновления (в вашем случае таковая имелась в бэкапе, например)

    Накатил на неё обновление

    Выгрузил обновлённую конфу

    В проблемную базу загрузил выгруженную конфу

    Если честно, то я не понимаю, почему этот способ мог бы не помочь в вашем случае?

    Reply
  51. Патриот

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

    Reply
  52. mbreaker

    (54), (55) Патриот, если проблема возникает непосредственно в данном обновлении — этот способ действительно предпочтительнее, не спорю. Но наш случай куда более запущенный. Коллега после первого «неудачного» изменения делал ещё несколько правок в конфигурацию (в т.ч. влияющую на структуру метаданных), т.к. не сразу обнаружил эту проблему. Т.е. в нашем случае не было «чистого» CF (как у Вас), не имеющего расхождений между объектами метаданных и versions.

    Кстати, предложенный способ мы тоже пробовали, но по вышеописанным причинам он нам не помог.

    Reply
  53. DAnry

    Спасибо за статью. Очень познавательно. Ведь в документации 1с этого нет, а с механизмом сравнения конфигурации работаем достаточно часто. В моей практике таких ситуаций ещё не было, но как говорят: «Предупреждён, значит вооружен»

    Reply
  54. AlexO

    (51) мало, пара тысяч всего.

    Reply
  55. AlexO

    (54) Патриот,

    Если честно, то я не понимаю, почему этот способ мог бы не помочь в вашем случае?

    Я тоже не понимаю, почему.

    В 32 я именно об этом и говорил, но ТС и народу интереснее обсуждать, кто из них лучше троллит )

    (56)

    Т.е. в нашем случае не было «чистого» CF

    В чем была проблема его получить? У вас битая была одна конфа (база), а не все. Иначе вообще непонятно — как «товарищ» определял, что он вносил какие-то изменения, если 1с ничего об этом не знала.

    Сервер сбоил и вырубался каждый раз, как только он вносил и пытался сохранить изменения? И каждый раз это приводило к битости версий объектов? Ну как-то так.

    Reply
  56. AlexO

    (57) DAnry,

    Ведь в документации 1с этого нет

    В документации 1с много чего нет.

    а с механизмом сравнения конфигурации работаем достаточно часто.

    Механизм сравнения здесь прилеплен сбоку, т.к. — вопросы 28, — это танцы с бубном, а не решение, тем более непонятно, что нашел в нем awa — это не его уровень (я не про «уровень эксперта и т.д. с шестью…»).

    Reply
  57. AlexO

    (56)

    Кстати, предложенный способ мы тоже пробовали, но по вышеописанным причинам он нам не помог.

    У вас в таком случае должнен был быть какой-то результат: положительный, отрицательный — какой-то. И этот результат — должен был отличаться от того, который получен и описан в статье.

    И судя по посту awa — результат должен был быть строго положительный, и решить все возникшие проблемы. Странно, что сам awa не развил свою идею 24. Хотя бы, чтобы логически завершить догадку.

    А так — решение так и повисло в воздухе, как я не просил сделать выводы.

    Reply
  58. mbreaker

    Предупреждал же меня webester: не трогай его — испачкаешься. Не послушал мудрого человека…

    (58) да, я уже понял — соответствие возраста аватару чувствуется в каждом посте, прискорбно только, что в таком юном возрасте человек себе такой характер уже заработал и продолжает его в себе развивать, считая, видимо, что быть *** нынче круто

    (59) (60) (61) AlexO, ещё раз повторю — на бессвязный бред я не отвечаю. Или научитесь корректно выражать свои мысли или перестаньте курить то, с чего так галюциногенит.

    P.S.

    но ТС и народу интереснее обсуждать, кто из них лучше троллит

    Сумасшедшему всегда кажется, что мир сошёл с ума. (из учебника по психиатрии).

    Если вам кажется, что вокруг вас идиоты, значит вы — центральный. (народная мудрость)

    Reply
  59. 1cmax

    (31) awa, (31) awa, Алексо тот еще тролль ))

    Reply
  60. 1cmax

    А у меня вопрос обратный. на рабочем сервере (скульная база ms sql) сделал полную загрузку конфигурации из cf-ника, сделал то же самое у себя (база файловая) . теперь у себя готовлю новый cf-ник с изменениями (скажем изменил 1 модуль и добавил 1 справочник). затем на рабочем сервере делаю сравнить,объединить и внезапно сравнение идет по всем объектам, а не по моим измененным. как быть в этой ситуации?

    Reply
  61. AlexO

    (64) 1cmax, у главных троллей спроси — они с тобой общаются охотно.

    Reply
  62. mbreaker

    (65) AlexO, для людей с:

    • отсутствием чувства такта
    • отсутствием чувства меры
    • ярко выраженным девиантным поведением
    • отсутствием аналитического мышления
    • деградированным ассоциативным мышлением

    я постараюсь в менее завуалированном виде донести смысл постскриптума из своего последнего сообщения.

    Троллю всегда кажется, что троллят его, а не он.

    Если вам кажется, что вокруг вас одни тролли, значит вы — «главный троль».

    P.S. интересно, до человека когда-нибудь дойдёт, что над его попыткам изобразить из себя пуп земли стебётся уже бОльшая часть сообщества? Или он так и будет продолжать закапывать себя своими «взрослыми» репликами уровня детского сада?

    Хотя… пубертатный период — это страшная вещь… мозг ведь напрочь гормонами захлёстывает! Может зря я с ним так…)))

    Reply
  63. mbreaker

    (64) 1cmax, в первую очередь сравнить идентификаторы объектов метаданных из этих конфигураций (мало ли, может разъехались, потом возвращать трудно будет), затем по предложенному awa алгоритму проверить versions.

    Reply
  64. kosmo0

    Полагаю что как вариант решения проблемы (посмотреть различия не типовыми методами) использование V8Reader

    Reply
  65. kosmo0

    Вот вы фантазеры. Напридумывали невесть что. 🙂

    Делал изменения в конфе, на последнем шаге — «обновить конфигурацию базы данных» — приключился вылет конфигуратора с сообщением про нехватку памяти. Ради интереса послал запрос в техподдержку 1С. Дал ссылку на эту статью. Попросил подтвердить или опровергнуть вероятность не корректной работы механизма сравнения конфигураций.

    Официальный ответ —

    «У нас нет таких данных.

    Если у вас на текущем релизе платформы 8.3.7.1949 есть какие-то проблемы при обновления вашей измененной конфигурации, то пришлите подробное их описание со скриншотами и пояснениями, что неправильно работает.

    Объединение объемных конфигураций рекомендуем выполнять на хороших процессорах и на 64 разрядных ОС»

    Сидите тут, придумываете. Техподдержка лучше вас знает. 🙂

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *