Рекурсия тестирования баз 1С. Когда однократного тестирования базы недостаточно

Здравствуйте, коллеги. Хочу поделиться с вами историей, с которой вы, возможно сталкивались или еще столкнетесь.

В работе с базами 1С, в данном случае речь пойдет о Рознице 2.2, я столкнулся с необъяснимыми проблемами баз данных клиентов. В основном это были случаи неработающего обмена РИБ и ошибка загрузки файловой базы в серверную.

Например, с РИБ, все стандартные операции тестирования, анализа ошибок обмена, загрузки файла обмена с FTP на рабочую машину и тп, не помогали. Замучавшись с базой, и отчаявшись, я начал последовательное тестирование базы данных по схеме: тестирование через утилиту chdbfl — тестирование в конфигураторе — тестирование через утилиту chdbfl — тестирование в конфигураторе — и так в своеобразной рекурсии, пока тестирование в конфигураторе не покажет отсутствие ошибок. Раньше, несмотря на весь опыт, мне и в голову бы не пришло делать такую рекурсию, я всегда думал, что однократных тестирований хватает за глаза. Однако, то ли Розница 2.2 такая, то ли платформа, то ли у меня не так уж и много опыта, но я реально столкнулся с двумя случаями, когда эта рекурсия тестирования необходима.

Ниже подробное описание ситуации, на примере, исправления ошибки загрузки файловой Розницы 2.2 в серверную базу данных.
Итак, у меня стояла задача, перевести файловую базу(Розница 1.0, кастомизированная) в серверный режим. База эта, надо сказать, была достаточно проблемной, на нее было привязано порядка 20 РИБ магазинов, сама она за полтора года работы разрослась до 5 ГБ. Итак, мы поставили сервер 1С, SQL, развернули пустую базу. Далее я, как обычно, выгрузил dt файл и решил его загрузить его в данную SQL базу. Однако, при загрузке 1С выдала ошибку — не все данные были загружены.
Ествественно, несмотря на то, что база выглядела рабочей, с ней нельзя было дальше работать, неизвестно к чему бы это привело.
Я приступил к поиску и исправлению ошибок. Сделал физическое тестирование через утилиту, сделал тестирование в конфигураторе. Физическое ошибок не выявило, в конфигураторе ошибки обнаружились, исправились. Но база так и не загрузилась, выдавала ошибку. Не буду описывать, что я далее делал для исправления данной проблемы и как я дошел до решения.
Скажу лишь в чем данное решение заключалось. Мне пришлось сделать следующее:

1.физическое тестирование через утилиту, далее тестирование логической и ссылочной целостности в конфигураторе.

2.физическое тестирование через утилиту, далее тестирование логической и ссылочной целостности в конфигураторе.            

3.физическое тестирование через утилиту, далее тестирование логической и ссылочной целостности в конфигураторе.

Нет, я не ошибся при написании данной статьи. Именно так, я несколько раз подряд повторял данную процедуру, при этом физическое тестирование ошибок так и не показывало, а тестирование в конфигураторе выявляло каждый раз новые ошибки. Я повторял данную процедуру до тех пор, пока тестирование в конфигураторе не показало мне заветное: «Тестирование начато»-«Тестирование закончено». После этого dt базы загрузился в северную версию успешно.

Как-то так. Спасибо за внимание, может, этот сомнительный опыт кому-то поможет.