TimeOut в UserConnection

[Raven13]

Доброго времени суток!

Столкнулся со следующей проблемой в DAX2009 SP1, используя класс UserConnection вызываю хранимую процедуру время выполнения, которой в среднем от одной минуты до пяти минут в зависимости от объема данных. Вызов в ахапке выполняется без ошибок, только вот результатов нет. Используя профайлер SQL Server выявил, что вызов хранимой процедуры заканчивается с ошибкой 2 - Abort, хотя если вызвать процедуру из SQL Management Studio выполнение не прерывается.

Так вызываю процедуру используя UserConnection:

    UserConnection             sqlConnection;
    Statement                     sqlStatement;
    Source                          sqlSource = strfmt("EXEC [dbo].[%1]", _procName);
    SqlStatementExecutePermission sqlPermission;
    ;
    sqlConnection = new UserConnection();
    sqlStatement  = sqlConnection.createStatement();

    sqlPermission = new SqlStatementExecutePermission(sqlSource);
    sqlPermission.assert();

    sqlStatement.executeUpdate(sqlSource);
    sqlStatement.close();

    CodeAccessPermission::revertAssert();

Сейчас удалось решить проблему следующим образом:

    System.Data.SqlClient.SqlConnection connection;
    System.Data.SqlClient.SqlCommand   command;
    System.Exception  e;
    
    SysSQLSystemInfo   systemInfo =  SysSQLSystemInfo::construct();
    CodeAccessPermission perm = new InteropPermission(InteropKind::ClrInterop);
    ;
    connection = new System.Data.SqlClient.SqlConnection(
        strfmt("Data Source=%1;Initial Catalog=%2;Integrated Security=True",
            systemInfo.getLoginServer(),
            systemInfo.getloginDatabase()));

    command = connection.CreateCommand();

    command.set_CommandText(_procName);
    command.set_CommandType(System.Data.CommandType::StoredProcedure);
    command.set_CommandTimeout(10 * 60);

    try
    {
        connection.Open();
        command.ExecuteNonQuery();
    }
    catch (Exception::CLRError)
    {
        e = ClrInterop::getLastException();
        while(e)
        {
            error(e.get_Message());
            e = e.get_InnerException();
        }
    }
    if (connection.get_State() == System.Data.ConnectionState::Open)
        connection.Close();

    CodeAccessPermission::revertAssert();

Собственно вопрос возможно ли установить Timeout для UserConnection?

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

UserConnection, теоретически, должен использовать ODBC-подключение. Посмотри в настройках собственно SQL-сервера, может там установлено ограничение на длительность выполнения запроса. Не базы, а именно SQL-сервера.

А, кроме того, в справке по классу Statement есть пример отлова ошибок исполнения

    Statement.executeUpdate(sql);
    print " Error code was: ", Statement.getLastError();
    print " Error message was '", Statement.getLastErrorText(), "'";

Может, "дело вовсе не в бобине" В смысле, ошибка не из-за timeoute происходит?

[Raven13]

Спасибо за ответ!

Цитата:

UserConnection, теоретически, должен использовать ODBC-подключение. Посмотри в настройках собственно SQL-сервера, может там установлено ограничение на длительность выполнения запроса. Не базы, а именно SQL-сервера.

Проверил, время ожидания удалённого запроса в секундах = 600, как и по умолчанию.

Цитата:

А, кроме того, в справке по классу Statement есть пример отлова ошибок исполнения

Я использовал этот метод отлова ошибок, при исполнении система ничего не выдавала (:

Цитата:

Может, "дело вовсе не в бобине" В смысле, ошибка не из-за timeoute происходит?

В первую очередь проверил свою хранимую процедуру, убрал все подозрительные инструкции, использование курсоров, оптимизировал саму процедуру, не помогло.
Пробовал комментировать часть процедуры и выполнять частями, в какой то момент процедура начала отрабатывать, но после включения самой "тяжелой" части процедуры снова результата не было.

Отмечу, что при использовании SqlCommand без set_CommandTimeout выполнение завершалось с ошибкой время ожидания запроса истекло, по этому я и сделал вывод, что проблема в том что истекает время исполнения запроса.

[fed]

На всякий случай спрошу: А у вас в хранимую процедуру добавлен оператор "SET NOCOUNT ON"?
Просто я однажды разбирался, почему хранимая процедура замечательно работает из SQL Management Studio, но валится на полпути при запуске из Connection. (При этом никаких кодов ошибки не возвращается, просто где-то посредине логики хранимка завершается).
Оказалось что из за того что SET NOCOUNT не стоял, все информационные сообщения о том что столько то записей обновлено, сохранялись в каком-то внутреннем буфере аксаптовского соединения.После того как буфер переполнялся, соединение автоматически аварийно завершалось, без выдачи какой-либо ошибки в Аксапту...

После вставки SET NOCOUNT ON в самое начало хранимой процедуры - все вылечилось...

[Raven13]

Цитата:

После вставки SET NOCOUNT ON в самое начало хранимой процедуры - все вылечилось...

Интересная информация, сегодня обязательно проверю, Спасибо!

[Raven13]

После добавление в процедуру SET NOCOUNT ON, всё заработало

Всем спасибо, тему можно закрывать.

[Player1]

Хочется добавить 5 копеек.
Имеем хранимую процедуру с SET NOCOUNT ON, вызываемую классом через UserConnection, всё работает в куче отчетов.
Стали дергать класс из 1С8 с помощью бизнес-коннектора, работает, но в Журнал трассировок (Ах3.0) после каждого вызова процедуры пишется "ошибка" типа QueryTime. Вроде работает и ладно, но неприятно.
На форуме нахожу пост и еще раз вызов хранимых процедур где люди используют для подключения класс OdbcConnection, подменил и в итоге ошибка пропала, а общее время сбора данных снизилось с 3:40 до 17сек.