Перенос устаревшей, но все еще активно используемой системы 1С:Предприятие 7.7 на современные версии Microsoft SQL Server является частой и порой весьма сложной задачей. Многие компании продолжают использовать 1С 7.7 из-за специфических конфигураций, большой базы данных или нежелания переходить на 1С 8.х. При этом возникает необходимость обновить серверное окружение, включая операционную систему и СУБД, до более актуальных и поддерживаемых версий. В этой статье мы подробно разберем, как осуществить такую миграцию, какие подводные камни нас ожидают, и как справиться с наиболее распространенными проблемами, включая расхождение остатков.
Основной вопрос, который возникает при попытке перенести базу 1С 7.7 с SQL Server 2008 R2 (или более старых версий) на SQL Server 2019, заключается в сохранении работоспособности системы и целостности данных, в частности, корректности остатков, что является критически важным для любого учета.
Прежде чем углубляться в технические детали, мы должны понимать официальную позицию фирмы "1С". Продукты "1С:Предприятие 7.7" разрабатывались в период с 1999 по 2003 год и были предназначены для работы с устаревшими операционными системами (Windows 95, 98, NT 4.0, 2000, XP, Server 2003) и версиями СУБД Microsoft SQL Server (6.5, 7.0, 2000). Официально "1С" рекомендует использовать продукты системы "1С:Предприятие 8" для новых внедрений.
Однако на практике многие пользователи продолжают эксплуатировать 1С 7.7, сталкиваясь с необходимостью ее адаптации к современным IT-инфраструктурам. Это вынуждает нас искать обходные пути и использовать неофициальные решения, одним из которых является "секретный релиз".
При попытке запустить 1С 7.7 на SQL Server 2019 без предварительной подготовки, как правило, возникают различные проблемы совместимости, проявляющиеся в ошибках ODBC, невозможности сохранения конфигурации или некорректной работе с данными. Рассмотрим основные варианты решения этой задачи.
Наиболее эффективным и рекомендованным сообществом решением для обеспечения совместимости 1С 7.7 с современными версиями SQL Server является применение так называемого «секретного релиза», или Solution7. Этот подход значительно упрощает процесс и минимизирует необходимость в ручных исправлениях или «плясках с бубном».
Solution7 – это прокси-технология, которая действует как посредник между платформой 1С 7.7 и SQL Server. Мы понимаем ее как набор файлов (как правило, DLL), которые помещаются рядом с исполняемыми файлами 1С 7.7. Она перехватывает и модифицирует запросы от 1С к серверу, адаптируя их под современные стандарты SQL Server. Solution7 также подменяет проверку версии SQL Server, что позволяет 1С 7.7 «думать», что она работает с официально поддерживаемой старой версией SQL, хотя фактически она взаимодействует с SQL Server 2019, 2017, 2012 или другой новой версией.
Критически важно отметить, что применение Solution7 позволяет избежать необходимости в «патченых DLL-ках» типа BkEnd.dll через hex-редактирование, что может быть нестабильным и требует глубоких знаний. Вместо этого используются специальные файлы-обертки (например, BkEnd.dll малого размера, которая перенаправляет вызовы к оригинальной BkEnd0.dll, или связка из нескольких DLL, таких как BkEndUtls.dll), что делает решение более чистым, стабильным и поддерживаемым сообществом.
Данное решение является разработкой сообщества и доступно на специализированных ресурсах для разработчиков 1С, таких как Infostart. Мы рекомендуем искать публикации автора spock, который является одним из создателей и активных распространителей Solution7.
Опыт пользователей показывает, что 1С 7.7 (в том числе на релизе 27.7) успешно работает с MS SQL Server 2019, SQL Server 2017 и SQL Server 2012 при использовании Solution7. Это делает Solution7 универсальным инструментом для адаптации 1С 7.7 к современным серверным окружениям.
Хотя «секретный релиз» в значительной степени снимает проблемы совместимости, вопрос режимов совместимости базы данных (Compatibility Level) все же может возникать и влиять на производительность или стабильность. Уровень совместимости определяет, как SQL Server обрабатывает определенные запросы и использует оптимизатор запросов.
В процессе миграции базы данных с SQL Server 2008 R2 на 2019, исходная база могла иметь режим совместимости «SQL Server 2000 (80)». При восстановлении на SQL Server 2019, база данных может сохранить этот уровень или быть автоматически обновлена до более высокого. Мы выясним, что для 1С 7.7 с SQL Server 2005 и 2008 R2 часто требовался именно уровень совместимости «SQL Server 2000 (80)». Однако для более новых версий SQL Server (например, 2017 или 2019) при использовании Solution7, многие пользователи успешно работают с уровнем совместимости, соответствующим самой версии SQL Server.
Например, для SQL Server 2019 это будет уровень 150, для SQL Server 2017 – уровень 140, для SQL Server 2012 – уровень 110.
Для изменения режима совместимости базы данных мы используем команду ALTER DATABASE. Рассмотрим примеры установки уровня совместимости:
ALTER DATABASE [ИмяВашейБазы1С]
SET COMPATIBILITY_LEVEL = 150; -- Для SQL Server 2019
-- Если возникнут проблемы, можно попробовать предыдущие уровни,
-- но это менее предпочтительно с Solution7.
-- ALTER DATABASE [ИмяВашейБазы1С]
-- SET COMPATIBILITY_LEVEL = 140; -- Для SQL Server 2017
-- ALTER DATABASE [ИмяВашейБазы1С]
-- SET COMPATIBILITY_LEVEL = 110; -- Для SQL Server 2012
Где [ИмяВашейБазы1С] – это имя вашей базы данных 1С 7.7. Мы рекомендуем начать с нативного уровня совместимости для вашей версии SQL Server и снижать его только в случае возникновения специфических проблем.
sp_dboptionВ SQL Server 2012 и более поздних версиях системная хранимая процедура sp_dboption, которую активно использовала 1С 7.7 для настройки различных параметров базы данных (например, для переключения в монопольный режим, настройки опций репликации и т.д.), была удалена. Вместо нее для настройки большинства параметров базы данных следует использовать команду ALTER DATABASE, а опции, связанные с репликацией, настраиваются через sp_replicationdboption.
sp_dboption влияет?
Мы выясним, что эта процедура вызывается платформой 1С 7.7 в двух основных сценариях: при запуске системы в монопольном режиме и при сохранении конфигурации. Если 1С не может найти или выполнить эту процедуру, возникают ошибки, что делает невозможной работу с базой или ее администрирование.
Solution7, как правило, обходит эту проблему. Он перехватывает вызовы sp_dboption от 1С и заменяет их на эквивалентные команды ALTER DATABASE, или же игнорирует эти вызовы, если они не критичны для функционирования в современной версии SQL Server. Этот механизм позволяет 1С 7.7 работать без ошибок, связанных с отсутствием sp_dboption. В редких случаях, если Solution7 не используется, некоторые администраторы пытались «позаимствовать» эту хранимую процедуру из старой версии SQL Server и восстановить ее в базе master новой версии, но это является крайне рискованным, неподдерживаемым подходом, который может привести к непредсказуемым проблемам и не рекомендуется.
Теперь мы подробно разберем шаги, необходимые для корректного переноса базы данных с SQL Server 2008 R2 на SQL Server 2019.
Перед переносом базы данных крайне важно убедиться в ее целостности и подготовить ее для миграции. Мы рекомендуем выполнить следующие действия:
Мы запустим команду DBCC CHECKDB на исходной базе данных. Это поможет выявить и, возможно, исправить любые повреждения структуры базы данных до начала миграции.
DBCC CHECKDB ([ИмяИсходнойБазы1С]) WITH NO_INFOMSGS, ALL_ERRORMSGS;
Это наш страховочный полис. Мы создадим полный бэкап базы данных, который позволит нам вернуться к исходному состоянию в случае непредвиденных проблем.
Автор в сообщении 0 задавал вопрос о промежуточной выгрузке/загрузке. Действительно, иногда полезно на исходном SQL Server (2008 R2) сначала перевести базу в нативный режим 2008 (если она была в режиме 2000), затем выполнить штатную выгрузку и загрузку информационной базы 1С 7.7 средствами самой платформы 1С. Это может помочь выявить скрытые проблемы или нарушения целостности данных до переноса на новую платформу SQL Server.
Наиболее надежный и рекомендуемый способ переноса базы данных – это стандартная процедура backup / restore. Мы создадим резервную копию базы данных на исходном SQL Server 2008 R2 и восстановим ее на целевом SQL Server 2019. Важно использовать SQL Server Management Studio (SSMS) для этих операций, так как она предоставляет удобный графический интерфейс и контроль над процессом.
Мы откроем SSMS на сервере с SQL Server 2008 R2. В обозревателе объектов (Object Explorer) мы найдем нашу базу данных 1С 7.7. Правой кнопкой мыши кликнем на нее, перейдем в меню «Задачи» (Tasks) -> «Резервное копирование» (Backup). В диалоговом окне мы убедимся, что тип резервной копии установлен на «Полная» (Full). Укажем путь для сохранения файла бэкапа (.bak), например, на локальный диск или сетевой ресурс, к которому есть доступ.
После создания бэкапа мы скопируем файл .bak на сервер с SQL Server 2019. Затем откроем SSMS на SQL Server 2019. В обозревателе объектов правой кнопкой мыши кликнем на папку «Базы данных» (Databases) -> «Восстановить базу данных» (Restore Database). В окне восстановления в разделе «Источник» (Source) выберем «Устройство» (Device) и с помощью кнопки «…» добавим наш файл .bak. Убедимся, что целевое имя базы данных в разделе «Назначение» (Destination) указано корректно. При необходимости, на вкладке «Файлы» (Files) мы можем указать новые пути для файлов данных (.mdf) и логов (.ldf) на целевом сервере. На вкладке «Параметры» (Options) мы можем выбрать опции перезаписи существующей базы данных, если такая уже есть.
Важно помнить, что прямое обновление (in-place upgrade) SQL Server 2008 R2 до 2019 года не поддерживается напрямую из-за существенных изменений в операционных системах и архитектуре. Поэтому миграция на новый сервер через бэкап/восстановление является стандартным и предпочтительным вариантом.
После успешного восстановления базы данных мы выполним следующие важные шаги для ее адаптации к новой среде SQL Server 2019:
Как мы уже обсуждали, мы установим оптимальный режим совместимости, соответствующий SQL Server 2019:
ALTER DATABASE [ИмяВашейБазы1С]
SET COMPATIBILITY_LEVEL = 150; -- Для SQL Server 2019
После переноса базы данных на новую версию SQL Server статистика по таблицам может быть неактуальной. Неактуальная статистика приводит к тому, что оптимизатор запросов SQL Server строит неоптимальные планы выполнения, что негативно сказывается на производительности запросов 1С 7.7. Мы обновим статистику для всех таблиц в базе данных:
EXEC sp_updatestats;
1С 7.7 по умолчанию использует SQL Server аутентификацию. Мы должны убедиться, что SQL Server работает в смешанном режиме аутентификации (Windows и SQL Server аутентификация). Это настраивается в свойствах сервера. Также мы зададим надежный пароль для встроенной учетной записи SA, если он еще не установлен.
В SQL Server Configuration Manager мы убедимся, что протокол TCP/IP включен для доступа к серверу по сети. Также, если возникают проблемы с подключением, можно попробовать отключить клиентский протокол SharedMemory, так как иногда он может вызывать конфликты.
Мы создадим отдельного пользователя SQL Server для работы с базой 1С 7.7 и предоставим ему необходимые права, как правило, db_owner для базы 1С. При создании базы данных (или после ее восстановления) для 1С 7.7 важно, чтобы имя базы не начиналось с цифры или содержало пробелы. Также мы установим созданного пользователя в качестве владельца базы данных 1С.
Проблема «остатки не бьются» после миграции является одной из самых тревожных и часто приводит к ступору. Мы выясним, что она не всегда связана с версией SQL Server или режимами совместимости, а может быть вызвана предыдущими некорректными действиями с данными, совершенными в исходной базе.
Если автор ранее занимался «дедупликацией регистров» или вручную «выпиливал дубликаты движений» напрямую из таблиц базы данных (например, из таблиц RAxxxx), это могло нарушить целостность агрегатов и итогов, которые 1С 7.7 рассчитывает и хранит.
Мы должны понимать, что при выполнении штатной выгрузки-загрузки информационной базы 1С (даже на одном и том же движке) система принудительно пересчитывает все итоги. Если исходная база содержала нарушения целостности из-за ручных правок, пересчитанные итоги на новом сервере (или даже на старом) могут не совпадать с «красивыми» цифрами, которые были получены после варварского вырезания строк, но без полного пересчета итогов платформой 1С. Таким образом, расхождение остатков может быть проявлением скрытых проблем в самой структуре данных, а не в процессе миграции СУБД.
Прежде всего, вернемся к исходной базе на SQL Server 2008 R2. Запустим служебную обработку 1С 7.7 «Тестирование и исправление ИБ» (часто это внешний отчет TIS.ert или аналогичная встроенная функция). В ней мы выполним следующие критически важные действия:
_RAxxxx и _RGxxxx).Если после пересчета итогов на старом сервере остатки также «поедут» (т.е., отчеты по остаткам покажут другие цифры, чем до этого), это явно указывает на проблему в самих данных и их внутренней целостности, а не в процессе миграции SQL Server. В таком случае, прежде чем переносить базу, необходимо будет разобраться с этими расхождениями на исходном сервере.
После выполнения пересчета итогов на исходной базе и ее проверки, мы сделаем контрольные отчеты по остаткам (например, оборотно-сальдовую ведомость, ведомость по складу) за ключевые периоды. Затем, после успешной миграции на SQL Server 2019 и настройки с Solution7, мы запустим те же отчеты на новой базе и сравним результаты. Если они совпадают, значит, проблема была в исходных данных до миграции, и теперь данные приведены к консистентному состоянию.
В некоторых случаях, даже если данные целостны, производительность запросов или даже особенности их выполнения могут измениться из-за обновления оценщика кратности (Cardinality Estimator) в SQL Server. Этот компонент, отвечающий за оценку количества строк, которые вернет операция, был существенно обновлен, например, начиная с версии SQL Server 2014. Изменения в нем могут приводить к тому, что SQL Server строит иные, возможно, менее оптимальные планы выполнения запросов для старого кода 1С 7.7, что может проявляться в замедлении работы или даже в тонких различиях в результатах.
Если мы подозреваем, что проблема кроется в этом, мы можем временно включить старый оценщик кратности для нашей базы данных. Это можно сделать на уровне базы данных или на уровне запроса. Для базы данных используем:
ALTER DATABASE SCOPED CONFIGURATION
SET LEGACY_CARDINALITY_ESTIMATION = ON
FOR [ИмяВашейБазы1С];
Это может помочь вернуть поведение запросов, характерное для старых версий SQL Server, и потенциально устранить проблемы, связанные с оптимизацией.
При работе 1С 7.7 на новых версиях Windows Server (например, 2019) и SQL Server 2019 могут возникать ошибки ODBC, даже при использовании Solution7. Эти ошибки часто указывают на проблемы с подключением или несовместимостью драйверов.
Мы установим SQL Server Native Client или более новый Microsoft ODBC Driver for SQL Server. Старые драйверы «SQL Server ODBC Driver» или «SQL Server» (идущие в комплекте с Windows) могут быть несовместимы с современными функциями, протоколами безопасности или особенностями работы SQL Server 2019. Эти драйверы можно скачать с официального сайта Microsoft. Установка соответствующего клиента на сервер, где работает платформа 1С 7.7, или на клиентские машины, с которых осуществляется доступ к базе, часто решает проблемы с подключением.
Мы проверим, запущены ли службы SQL Server (основной экземпляр) и SQL Server Browser на сервере с SQL Server. Убедимся, что протокол TCP/IP включен в SQL Server Configuration Manager и что брандмауэр Windows (как на сервере 1С, так и на сервере SQL) не блокирует порты SQL Server (по умолчанию это порт 1433 для экземпляра по умолчанию).
Следуя этим рекомендациям, мы значительно повысим шансы на успешную миграцию 1С 7.7 на SQL Server 2019 и обеспечим стабильную работу вашей информационной базы.
Критически важно выполнять все операции по миграции и настройке в непроизводственной, тестовой среде. Мы должны тщательно протестировать все функции 1С 7.7, включая формирование отчетов, проведение документов, закрытие периодов, работу регламентных задач, на перенесенной базе. Только после того, как мы убедимся в полной работоспособности и корректности данных, базу можно переводить в рабочую эксплуатацию.
В некоторых случаях, даже при успешно работающем SQL Server 2019, сама платформа 1С 7.7 может иметь проблемы с запуском на операционной системе Windows Server 2019. Если возникают необъяснимые ошибки, мы рассмотрим вариант запуска 1С 7.7 в более старых, но еще поддерживаемых операционных системах (например, Windows Server 2008 R2 или Windows Server 2012) на виртуальной машине, при этом подключив ее к базе данных, размещенной на SQL Server 2019. Этот гибридный подход позволяет изолировать старое приложение от несовместимостей современной ОС.
Мы обязательно задокументируем все шаги, настройки, использованные версии программного обеспечения (SQL Server, Solution7, драйверы ODBC), а также выявленные и решенные проблемы. Это поможет при дальнейшей поддержке и возможных будущих миграциях.
Миграция 1С 7.7 на современный SQL Server – это вызов, но с правильным подходом и инструментами, такими как Solution7, мы можем успешно его преодолеть, обеспечив долгую и стабильную работу важной для бизнеса системы. Для организации регулярного обслуживания базы данных после миграции можно использовать инструкцию по настройке регламентных операций в MS SQL Server под 1С.