При поддержке старых систем на платформе 1С:Предприятие 7.7 мы часто сталкиваемся с необходимостью интеграции с внешними базами данных, в том числе с такими же "древними" версиями СУБД, как MS SQL Server 2000. Несмотря на возраст технологий, задачи по обмену данными остаются актуальными. В этой статье мы подробно разберем комплекс проблем, возникающих при настройке взаимодействия между 1С 7.7 и SQL Server 2000 через ODBC/ADO, проанализируем ошибки шифрования, исправим отображение кириллицы и научимся корректно обрабатывать специфические типы данных.
Первая проблема, с которой мы можем столкнуться при попытке установить соединение из среды 1С (или при настройке системного DSN) к SQL Server 2000, — это ошибка, связанная с поддержкой шифрования протокола.
Текст ошибки выглядит следующим образом:
[Microsoft][ODBC SQL Server Driver][Shared Memory]Encryption not supported on SQL Server
TESTS FAILED!
Давайте разберемся в причинах. Эта ошибка часто возникает, когда клиентский драйвер (особенно если мы используем более новые версии ОС или драйверов на клиенте) пытается установить защищенное соединение, а SQL Server 2000 (особенно работающий на старой ОС, например, Windows 2000) либо не настроен для этого, либо используется протокол Shared Memory, который не поддерживает требуемый уровень шифрования.
Чтобы устранить эту проблему, нам необходимо выполнить настройку клиентской части. Рассмотрим варианты решения:
cliconfg.exe). В ней необходимо убедиться, что снята галочка "Force protocol encryption" (Принудительное шифрование протокола).cliconfg.exe переместим TCP/IP или Named Pipes выше в списке приоритетов, чем Shared Memory.Encrypt=no;
После успешного подключения мы можем столкнуться с тем, что при записи или чтении русских букв мы видим вопросительные знаки (??????). Это классическая проблема несоответствия кодовых страниц (Collation).
Платформа 1С 7.7 не является Unicode-приложением и работает с однобайтовыми кодировками (в нашем случае CP1251). SQL Server же может хранить данные как в Unicode (типы nchar, nvarchar), так и в ANSI (char, varchar).
Для корректной работы с кириллицей нам необходимо проверить настройки на стороне SQL Server:
1. Проверка Collation базы данных и полей.
Если при создании сервера или базы данных была выбрана кодировка по умолчанию (часто это SQL_Latin1_General_CP1_CI_AS), то русские символы в полях типа varchar будут испорчены. Нам необходимо убедиться, что для строковых полей, куда пишет 1С, установлен Collation Cyrillic_General_CI_AS.
Если таблица уже создана с неверной кодировкой, изменим её командой SQL:
ALTER TABLE MyTable ALTER COLUMN MyTextField VARCHAR(100) COLLATE Cyrillic_General_CI_AS
2. Особенности работы через ADO.
Если мы используем поля типа nvarchar (Unicode), то при передаче строковых литералов в SQL-запросе из 1С, рекомендуется добавлять префикс N перед строкой:
StrSQL = "INSERT INTO MyTable (Name) VALUES (N'" + СокрЛП(ИмяКлиента) + "')";
Однако для 1С 7.7 наиболее надежным вариантом остается использование полей varchar с правильно настроенным Cyrillic Collation.
При получении данных из внешней SQL-базы в 1С 7.7 через объект ADODB.Recordset часто возникают сложности с интерпретацией типов данных.
Тип BIT (Логический)
Поле типа bit в SQL Server возвращает значения 0 или 1. Однако при чтении в 1С это может вызвать неудобства, так как 1С не всегда корректно преобразует это в Булево (которого в явном виде в языке 7.7 как типа COM-объекта может не быть). Чтобы избежать проблем, приведем тип к целому числу прямо в запросе:
SELECT CAST(IsActive AS INT) as IsActiveInt FROM Users
Теперь в 1С мы получим обычное число 0 или 1.
Тип NUMERIC/DECIMAL (Числа с фиксированной точкой)
Драйверы ADO часто преобразуют SQL-типы высокой точности (например, numeric(15,2)) в тип с плавающей точкой (Double / Real) на стороне клиента. Это приводит к появлению "хвостов" точности. Вместо 10.00 мы можем получить 9.99999999.
Рассмотрим способы решения этой проблемы:
Число().
SELECT CAST(Summa AS VARCHAR(20)) as SummaStr FROM Docs
В коде 1С:
ТочнаяСумма = Число(RS.Fields("SummaStr").Value);
INT, а в 1С поделить обратно. Но это менее гибкий метод.Часто в контексте интеграции возникает задача загрузки данных из файлов Excel современного формата (.xlsx). Стандартные методы через OLE Automation (Excel.Application) могут быть медленными или недоступными, если офис не установлен на сервере.
Используем подход через ADO, который работает быстро и требует только наличия драйверов. Для чтения формата .xlsx нам понадобится провайдер Microsoft.ACE.OLEDB.12.0 (компонента Microsoft Access Database Engine).
Сформируем строку подключения для чтения Excel:
Connection = CreateObject("ADODB.Connection");
ConnectionString = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" + ПутьКФайлу + ";Extended Properties=""Excel 12.0 Xml;HDR=YES;""";
Connection.Open(ConnectionString);
Обратите внимание на параметр Extended Properties. Значение Excel 12.0 Xml указывает драйверу, что мы работаем с новым форматом XML (xlsx). Параметр HDR=YES означает, что первая строка файла содержит заголовки колонок.
Далее мы можем обращаться к данным листа как к обычной таблице SQL:
RS = CreateObject("ADODB.Recordset");
RS.Open("SELECT * FROM [Лист1$]", Connection);
Пока RS.EOF() = 0 Цикл
// Чтение данных
ЗначениеПоля = RS.Fields("НазваниеКолонки").Value;
RS.MoveNext();
КонецЦикла;
Этот метод работает значительно быстрее, чем перебор ячеек через OLE, и позволяет использовать мощь SQL (фильтрацию WHERE, группировки) прямо при чтении файла.