Как я чинил базу клиента
У клиента не накатывалось обновление третьей Бухии в файловой базе 7 Гб. При обновлении конфигурации базы данных писало про ошибку размерности в SDBL.
Рекомендованные трюки по решению проблемы не помогли.
Тогда я попробовал загрузить базу из DT в SQL. Не получилось, выскочила ошибка:
Ошибка загрузки информационной базы. В информационную базу загружены не все данные
по причине:
Попытка вставки неуникального значения в уникальный индекс:
Microsoft SQL Server Native Client 11.0: Выполнение инструкции CREATE UNIQUE INDEX прервано, поскольку обнаружен повторяющийся ключ для объекта с именем "dbo._AccRgED1011" и индекса с именем "_AccRgE1011_ByPeriod_TRNRN". Повторяющееся значение ключа: (0, янв 1 2001 12:00AM, 0x00000000, 0x00000000000000000000000000000000, 0, 0x00000000000000000000000000000000, 0).
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=10, native=1505, line=1
С помощью обработки "Анализ метаданных" с инфостарта я посмотрел, что таблица AccRgED1011 относится к регистру бухгалтерии и решил сделать ход конем, уже опробованный ранее.
Удалил из конфигурации регистр бухгалтерии, для этого пришлось снять её с поддержки. После этого накатил обратно нормальную конфигурацию, конфигурация встала. Накатил обновление - тоже встало.
Выгрузил из копии регистр бухгалтерии, перенес его обработкой "Выгрузка-загрузка" в починенную базу. Все получилось.
Сверил ОСВ в исходно и вылеченной базах. Получилось расхождение. Но не по оборотам, а по остаткам. Сначала запаниковал, но потом понял, что в исходной базе были битые итоги, так что там дебет мог с кредитом не сходиться.
Все-таки корректировка регистров в 1С сделано не до конца верно. Нельзя убить битые записи. Это началось еще в 8.1 и до 8.3 до сих пор еще не решено. Приходится удалять битый регистр целиком. На прошлой работе в конфигурации "Розница 1.0" популярным кандидатом на кастрацию был регистр "Продажи". А тут в бухиях - регистр бухгалтерии.
Мало того, что 1С не гарантирует загрузку данных из DT-файла. По сути архивация через DT-файлы - это фикция, никто не гарантирует, что из этого файла данные загрузятся. Тут тоже странно, логично было бы пропускать битые записи при загрузке, а не прерывать загрузку. Ну это на совести 1С.
Ну, клиенту можно было бы отправить базу в 1С, там бы теоретически её бы пролечили, насчет сроков сказать не могу, гарантированного тайм-аута нет, но обычно долго не задерживают.