Хто не знає, chdbfl.exe - це стандартна програма відновлення та тестування фізичної цілісності бази 1С, що входить в комплект платформи. І всім вже давно відомо що chdbfl.exe робить тільки гірше в більшості випадків (в моїй практиці саме так).
А почалося все з дуже банальної помилки. Так як програмісти з 1С дуже люблять мудрувати, то під час чергового оновлення 1С: Бухгалтерія вивалилося наступне:
Зараз то я знаю, що ця помилка усувається очищенням кеша, але в той час я скористався саме chdbfl.exe і Конфігуратором (Тестування і виправлення). Помилка пішла і я легко оновився. Але на наступний день пролунав тривожний дзвінок бухгалтера: - Приїжджай!
По приїзду мене зустріла 1С з вискакують дампом при відкритті документа «Надходження товарів і послуг». Було вирішено зробити ще раз перераховані вище пункти. І о диво! Проблема була вирішена. Я з гордістю виїхав з організації, але при цьому забрав базу для тестування на своєму комп'ютері. Але не тут то було. Тепер вже інший документ вивалювався з дампом. Було вирішено відкласти все на завтра і спробувати щось зробити на своєму комп'ютері. І на цей раз мені допомогли такі ж кроки, як і раніше. «Тепер все» - думав я. Але не зовсім.
Через 2 тижні пролунав черговий дзвінок: - Звіти горять, приїжджай терміново!
На цей раз було все куди серйозніше. При перерахунку підсумків 1С видавала наступне:
Звіти, які вимагають підсумки видавали наступне:
Як і раніше, я скористався тими ж утилітами що і раніше, але результату це не дало. Як і не дало результату всілякі вивантаження / завантаження / збереження. Оновлення теж не проходило з невідомої мені причини:
Це мене поставило в глухий кут на 2 дня. За ці дні було перепробувано майже все. Багато радили подивитися план рахунків і видалити зайві субконто у цього рахунку. Але! Все було типове, ніяких змін не проводилося.
Рішення прийшло раптово і навіяно ось цієї статейки. Скачав всі програми зі статті і почав «колупати». Відкрив файл бази в Tool_1CD і після півгодини куріння і розуміння з'ясувалося що:
- _Acc - основна таблиця плану рахунків.
- _Acc_ExtDim - таблиця видів субконто плану рахунків, створюється для плану рахунків в тому випадку, якщо максимальна кількість субконто більше нуля.
У моєму випадку це таблиці _АСС13 і _АСС13_EXTDIM446 відповідно:
Отже, починається найцікавіше. Запам'ятовуємо поле _IDRREF нашого рахунку в таблиці _АСС13:
Переходимо в _АСС13_EXTDIM446 і намагаємося знайти цей ідентифікатор в поле _АСС13_IDRREF:
Ось вони, наші заповітні субконто. Але ж їх повинно бути три! Якимось незрозумілим і дивним чином Конфігуратор при реструктуризації і chdbfl.exe задвоілі субконто цього рахунку і тому вискакувала помилка. Зайві потрібно якось видалити. Для цього нам знадобитися ще одне поле з тієї ж таблиці, _KEYFIELD. Запам'ятовуємо все значення зайвих субконто. Має вийти наступне:
І так з кожним субконто. Потрібні нам рядки:
- a7c1920ebbd1a385484e55905724b6a1000001b0
- a7c1920ebbd1a385484e55905724b6a1000001b1
- a7c1920ebbd1a385484e55905724b6a1000001b2
Залишилася справа за малим. Змінимо першу цифру коду на 9 (можна взяти будь-яку іншу, але потрібно контролювати унікальність цього коду) і збережемо файл бази. Відкриваємо все це в 1С: Підприємство (для впевненості можна ще раз прогнати тестування і виправлення і chdbfl.exe) і радіємо відновленій і робочої базі.