Приветствую. 1С и DB2 сидят на разных серверах Win2k8 R2. Сервер с 1Сом — член домена, с DB2 — нет. Сервер 1С:Предприятия запущен под локальным пользователем. При создании ИБ в консоли управления сервером 1С получаю ошибку: "Error: line=868, file=src\DB2Connection.cpp, SQLCODE=-1390 SQL1390C Не определена или недопустима переменная среды DB2INSTANCE"
На сервере DB2 переменная определена, указывает на экземпляр "DB2".
Подскажите куда рыть?
Версия 1С - 8.3.5.1383
DB2 - 10.5 express-c с сайта IBM
(1) Asmody, судя по тому, что ошибка на сервере 1с - переменную надо определить на сервере 1с. Да и вообще проверить, установлен ли клиент ДБ2 на этом сервере (если он нужен и бывает вообще в природе).
1С официально поддерживает только DB2 10.1
Версия Express-C, поддерживаемая 1С:Предприятием, опубликована на сайте IBM
Поддерживается в режиме бета-тестирования из-за значительных изменений в архитектуре DB2
Меня поражает вездешняя рекомендация "включить пользователя, под которым запускается 1С, в группу DB2ADMINS". В случае двух standalone серверов это весьма оригинальное требование.
На платформах UNIX реестр профиля уровня экземпляра сохраняется в виде текстового файла в каталоге sqllib. В средах многораздельных баз данных каталог sqllib находится в файловой системе, совместно используемой всеми физическими разделами базы данных.
На платформах Windows, если пользователь выполняет ту же команду с узла "red", это значение переменной FOO будет видно только на узле "red" текущего экземпляра. Менеджер баз данных DB2 хранит реестр профиля уровня экземпляра в реестре Windows. Его значения недоступны другим физическим разделам базы данных. Чтобы задать переменные реестра на всех физических компьютерах, используйте команду "rah":
rah db2set -i FOO=BAR
Команда rah выполнит команду db2set на всех узлах ("red", "white" и "blue").
Можно использовать переменную DB2REMOTEPREG, чтобы для переменных реестра на компьютерах, не являющихся владельцами экземпляра, использовались значения переменных реестра на компьютере-владельце экземпляра. Это эффективный способ создания среды, в которой переменные реестра на компьютере-владельце экземпляра совместно используются всеми компьютерами этого экземпляра.
Предположим, что в предыдущем примере узел "red" - владелец экземпляра. Зададим переменную DB2REMOTEPREG на компьютерах "white" и "blue", чтобы использовать переменные реестра с компьютера "red":
(на red) ничего не делаем
(на white и blue) db2set DB2REMOTEPREG=\\red
Заданное значение DB2REMOTEPREG нельзя менять.
Вот как работает DB2REMOTEPREG:
Когда менеджер баз данных DB2 читает переменные реестра в Windows, сначала считывается значение DB2REMOTEPREG. Если переменная DB2REMOTEPREG задана, DB2 открывает реестр на удаленном компьютере, имя которого задано в DB2REMOTEPREG. Последующие операции чтения и изменения переменных реестра будут перенаправлены на этот удаленный компьютер.
Для обращения к удаленному реестру требуется, чтобы на удаленном компьютере была запущена служба удаленного реестра. Кроме того, учетная запись пользователя и всех службы DB2 должны иметь достаточный доступ к этому удаленному реестру. Поэтому для использования переменной DB2REMOTEPREG следует работать в среде домена Windows, чтобы можно было предоставить учетной записи домена необходимые полномочия на обращение к реестру.
При работе в среде Microsoft Cluster Server (MSCS) не нужно использовать переменную DB2REMOTEPREG. В конфигурации с MSCS, где все компьютеры входят в один кластер MSCS, переменные реестра сохраняются в реестре кластера. Поэтому они уже совместно используются всеми компьютерами в кластере MSCS и использовать переменную DB2REMOTEPREG в этом случае нет необходимости.
При работе в многораздельной среде с восстановлением после сбоев, где разделы базы данных распределены по нескольким кластерам MSCS, нельзя использовать переменную среды DB2REMOTEPREG для задания компьютера-владельца экземпляра, поскольку переменные реестра этого компьютера находятся в реестре кластера.
(12) AlexandrIII, Сервер SQL1 не входит в домен, он вообще сам по себе, в отдельной ethernet-сети, про всё остальное он вообще ничего не знает. Если грубо — он напрямую соединён шнурком со вторым eth-портом на ODINS.
По такой схеме сейчас работает сервер MSSQL. Отлично работает, без подпрыгиваний.