как узнать код ошибки при подключении к базе?

[Владимир Максимов]

1. Устанавливать что-либо автоматически - категорически не рекомендуется. У пользователя банально может не быть прав на эту операцию. Кроме того, как правило, подобные установки требуют перезагрузку операционной системы.

2. Как следствие, не надо здесь "мудрить". Произошла ошибка - просто прекращайте обработку. Далее пользователь должен Вам выслать снимок экрана с текстом ошибки или Вы ее записываете где-то себе в лог ошибок и ВРУЧНУЮ разбираетесь как с причиной, так и ищите пути исправления.

Это не тот случай, где нужно что-то автоматизировать. Время и силы, потраченные на подобную автоматизацию никогда не окупяться. Слишком много всего надо будет проверять. Например, может быть еще вылет по timeOut. Может быть не корректно указан логин/пароль. Да мало ли что еще...

Насчет обязательной установки драйвера мы у себя решили эту проблему следующим образом. Драйвер ставится на тот компьютер, где крутится AOS. Установка соединения и запросы выполняются на стороне сервера (RunOn = Server). Как следствие, нет необходимости ставить драйвера на клиентские машины.

[ice321i]

Если 4 то можно и через .NET.

#define.Port(    );
#define.Server('сервер на котором запущена служба');
System.Net.Sockets.TcpClient tcpClient;
;
tcpClient = new System.Net.Sockets.TcpClient();
tcpClient.Connect(#Server, #Port);
if(!tcpClient.Connected)
throw error("Сервер не доступен");

И не надо ни каких библиотек с собой тянуть)))

[CHESER85]

Цитата:

Сообщение от Владимир Максимов

1. Устанавливать что-либо автоматически - категорически не рекомендуется. У пользователя банально может не быть прав на эту операцию. Кроме того, как правило, подобные установки требуют перезагрузку операционной системы.

2. Как следствие, не надо здесь "мудрить". Произошла ошибка - просто прекращайте обработку. Далее пользователь должен Вам выслать снимок экрана с текстом ошибки или Вы ее записываете где-то себе в лог ошибок и ВРУЧНУЮ разбираетесь как с причиной, так и ищите пути исправления.

Это не тот случай, где нужно что-то автоматизировать. Время и силы, потраченные на подобную автоматизацию никогда не окупяться. Слишком много всего надо будет проверять. Например, может быть еще вылет по timeOut. Может быть не корректно указан логин/пароль. Да мало ли что еще...

Насчет обязательной установки драйвера мы у себя решили эту проблему следующим образом. Драйвер ставится на тот компьютер, где крутится AOS. Установка соединения и запросы выполняются на стороне сервера (RunOn = Server). Как следствие, нет необходимости ставить драйвера на клиентские машины.

Попробовал воспользоваться вашим советом, но, к сожалению, при установке RunOn=Server все равно запросы происходят на клиенте сам не знаю почему

[ice321i]

Вот рабочий пример проверки соединения по определенному порту сервера, проверял на 5, должно работать и для 4:

static void ConnectToServer(Args _args)
{
    System.Net.Sockets.TcpClient tcpClient;
    ;

    tcpClient = new System.Net.Sockets.TcpClient();
    
    try
    {
        tcpClient.Connect('www.yandex.ru', 80);

        if(tcpClient.get_Connected())
        {
            info("Сервер доступен");
            tcpClient.Close();
        }
    }
    catch(Exception::CLRError)
    {
        error("Ошибка при подключении к серверу");
    }
}

[konfet]

Цитата:

Сообщение от ice321i

Вот рабочий пример проверки соединения по определенному порту сервера, проверял на 5, должно работать и для 4:

static void ConnectToServer(Args _args)
{
    System.Net.Sockets.TcpClient tcpClient;
    ;

    tcpClient = new System.Net.Sockets.TcpClient();
...
}

В том-то и дело, что для 4-ки работает хреново
Иногда вылетает с эксепшеном, иногда без эксепшена - просто не доходит до конца кода.
И еще, помимо вылетов, важный недостаток - нельзя настроить таймаут, который определяет, сколько надо ждать ответа от удаленного сервера, перед тем как посчитать его недоступным.
Я нашел в сети простую утилитку, которая работает для серверов как внутри сети (за фаерволлом), так и вне ее. Работает примитивно, но зато надежно.
Использую прежде всего для определения доступности удаленного (связанного) SQL-сервера, по порту 1433.
Таймаут определен в три секунды, можно поставить и меньше.
Утилитку надо положить в каталог Include приложения.

#define.PingSuccess('1 successful, 0 failed')
#define.PingFailed('0 successful, 1 failed')
#WInAPI
static server boolean ping3(ServerName _ServerName, str 10 _port = '80')
{
    boolean res, xSuccess, xFailed;

//  одна секунда ожидания
    str templateStr = '-4 -n 1 -w 1 %1 %2 > %3';
    str paramStr, outputStr, commandStr;
    fileName xTCPingEXE;
    fileName xFileName, xDir;
    TextBuffer TextBuffer = new TextBuffer();
    Counter i;

    ;
    xDir = WinAPIServer::getTCPing(true);

    xTCPingEXE = WinAPIServer::getTCPing(false);
    xFileName = xDir + curUserId() + '_ping.txt';
    paramStr = strFmt(templateStr, _ServerName, _port, xFileName);
    commandStr = 'CMD /c ' + xTCPingEXE + ' ' + paramStr;

//  три секунды ожидания
    WinAPI_R::shellExecuteWait(commandStr, 3000);
    TextBuffer.fromFile(xFileName);
    outputStr = TextBuffer.getText();
    xSuccess = strscan(outputStr, #PingSuccess, 1, strlen(outputStr)) ? true : false;
    xFailed = strscan(outputStr, #PingFailed, 1, strlen(outputStr)) ? true : false;
    if (xSuccess == xFailed)
    {
        throw error("Непонятный результат пинга!");
    }

    WinAPIServer::deleteFile(xFileName);
    return xSuccess;
}

Метод, возвращающий (серверный) путь к экзешнику tcping.exe:

static server fileName getTCPing(boolean _directoryOnly = false)
{
    filename xdir, xfile;

    ;

    xdir = xInfo::directory(DirectoryType::Include) + @'TCPing\';
    xfile = xInfo::directory(DirectoryType::Include) + @'TCPing\tcping.exe';
    if (!WinAPIServer::fileExists(xfile))
    {
        throw info(strFmt('   %1', xfile));
    }
    return _directoryOnly ? xdir : xfile;
}

метод shellExecuteWait() взят отсюда.

[Владимир Максимов]

Цитата:

Сообщение от CHESER85

Попробовал воспользоваться вашим советом, но, к сожалению, при установке RunOn=Server все равно запросы происходят на клиенте сам не знаю почему

Еще раз напомню, что установка соединения и выполнения запроса происходит в классах CCADO... (CCADOConnection, CCADOCommand, CCADOFields, CCADOField, CCADORecordSet) Другими словами, надо смотреть свойство RunOn у этих классов.

В младших версиях Axapta у них это свойство было "Called From". Т.е. откуда вызвали, там и работают. Но вот в Ax2009 уже стоит Client. Посмотрите, что стоит в Вашей версии.

[CHESER85]

Цитата:

Сообщение от Владимир Максимов

Еще раз напомню, что установка соединения и выполнения запроса происходит в классах CCADO... (CCADOConnection, CCADOCommand, CCADOFields, CCADOField, CCADORecordSet) Другими словами, надо смотреть свойство RunOn у этих классов.

В младших версиях Axapta у них это свойство было "Called From". Т.е. откуда вызвали, там и работают. Но вот в Ax2009 уже стоит Client. Посмотрите, что стоит в Вашей версии.

Поменял у классов CCADO* значение RunOn на Server, и вот что выдало при запуске:
Сбой запроса на разрешение типа "InteropPermission".
(S)\Classes\InteropPermission\demand
(S)\Classes\COM\new
(S)\Classes\CCADOConnection\new - line 4
(C)\Jobs\GidInOutReport - line 20

Error Сообщение (08:18:21) Объект "COM" не может быть создан