Перевод старых баз на платформе 1С:Предприятие 7.7 с файлового формата DBF на клиент-серверный вариант (MS SQL Server) часто сопровождается рядом специфических проблем. Одной из самых частых трудностей является потеря или некорректный расчет итогов по регистрам накопления. Рассмотрим подробнее, почему после успешной, казалось бы, миграции на SQL Server 2008 R2 (или более новые версии) пропадают итоги, а стандартное тестирование и исправление базы не дает результатов. Разберем по шагам причины сбоев и методы их устранения.
Если стандартный пересчет служебных данных в конфигураторе проходит "тихо-мирно", но итоги не появляются, программисты часто прибегают к помощи внешних компонент, таких как 1CPP.dll, для прямого пересчета (выполнения SQL-запросов напрямую к таблицам базы). Проанализируем типичные препятствия на этом пути.
1. Ошибка загрузки компоненты:
Часто при запуске обработки система выдает сообщение, что компонента 1С++ не установлена, хотя сам файл 1CPP.dll лежит в каталоге BIN платформы 1С. Выясним причину: физического наличия файла недостаточно. Компоненту необходимо инициализировать в коде. В процедуре ПриОткрытии() обработки или в глобальном модуле должен быть вызван метод загрузки:
Если ЗагрузитьВнешнююКомпоненту("1CPP.dll") = 0 Тогда
Сообщить("Ошибка загрузки компоненты 1С++!");
КонецЕсли;
Также может потребоваться регистрация библиотеки в операционной системе с помощью утилиты regsvr32.exe, запущенной от имени администратора.
2. Ошибка "Недопустимое имя столбца 'sp'":
При попытке пересчитать итоги прямым запросом может возникнуть ошибка: State 42S22, native 207, message [Microsoft][ODBC SQL Server Driver][SQL Server]Недопустимое имя столбца "sp".
В архитектуре 1С 7.7 на SQL Server имена колонок для реквизитов и измерений формируются из префикса SP и уникального буквенно-цифрового идентификатора (например, SP1234). Если скрипт пересчета выдает такую ошибку, это означает, что он не смог корректно распарсить метаданные базы (возможно, из-за изменения структуры регистра или нестандартных идентификаторов) и сформировал неполный текст SQL-запроса.
3. Ошибка выхода даты за пределы диапазона (1753 год):
Это классическая архитектурная проблема при переходе с DBF на SQL. В процессе пересчета итогов система может выдать ошибку: Преобразование типа данных varchar в тип данных datetime привело к выходу значения за пределы диапазона, упоминая удаление итогов за период начиная с 01.01.1753.
Посмотрим на причину: в формате DBF дата документа может быть полностью пустой. Однако в MS SQL Server для типа данных DATETIME минимально допустимой датой является 1 января 1753 года. При выгрузке базы 1С заменяет все пустые даты в движениях на этот год. Когда система пытается пересчитать итоги с 1753 года по текущий день, происходит колоссальное переполнение, и пересчет аварийно завершается. Чтобы избежать этого, перед выгрузкой в SQL необходимо найти и исправить/удалить все документы и движения по регистрам (таблица RA) с пустой датой.
Представим ситуацию: вы успешно пересчитали итоги прошлых периодов, остатки на начало дня верные. Однако в процессе текущей работы пользователей при проведении приходной накладной на 4 штуки товара, остаток в отчетах увеличивается на 8 штук. Если ночью сделать пересчет итогов средствами SQL — все снова становится на свои места до первого проведения.
Проанализируем ситуацию. Платформа 1С:Предприятие 7.7.027 была разработана во времена MS SQL Server 2000. В современных версиях СУБД (начиная с 2005 и особенно в 2008 R2 / 2012) изменились механизмы работы с транзакциями, временными таблицами и планами запросов. Оригинальный исполняемый файл bkend.dll платформы 1С некорректно обрабатывает команды обновления таблицы итогов (RG) на новых серверах, что приводит к задвоению или неверному расчету данных "на лету".
Как решить проблему:
SQL Server 2000 (80).bkend.dll (например, решение от Secret) или специализированные врапперы (патч Romix), которые исправляют ошибки транзакций и некорректное формирование временных таблиц при расчете итогов.Разберем интересный нюанс, характерный для старых версий конфигурации "Торговля и Склад" (например, редакции 8.7). В таких базах разделение управленческого и финансового (бухгалтерского) учета часто реализовывалось через пустое измерение.
Если в регистр делается две записи, где одна привязана к конкретной фирме (Финансовый учет), а вторая имеет пустое значение фирмы (Управленческий учет), у многих возникает вопрос: не сходит ли с ума SQL от пустых полей?
Ответ: нет, пустые значения измерений платформой обрабатываются корректно. 1С передает пустое значение справочника в базу SQL не как NULL, а как строку из 9 пробелов. СУБД отлично с этим справляется, и на физическое разрушение итогов это никак не влияет.
Однако, если вы используете прямые SQL-запросы для построения собственных быстрых отчетов, вам необходимо помнить об этой архитектурной особенности. Если вы напишете простой агрегирующий запрос SELECT SUM(...) без фильтрации по измерению "Фирма", вы получите задвоенный результат (сложение упр. и фин. учета). В таких прямых запросах необходимо явно указывать условие фильтрации на пустое значение ($ПустойИД).
Подведем итог: Переход старой версии платформы на современные версии MS SQL требует предварительной подготовки данных (очистки пустых дат), обязательной настройки уровня совместимости базы данных на сервере и, в большинстве случаев, применения патчей для библиотеки платформы, отвечающей за работу с СУБД. Выполнение этих шагов гарантирует стабильную работу регистров накопления и верный расчет итогов.