Ошибка с подключением через ODBC + глюк с работой через connection

[Corel]

Ситуация такая: на работающем приложении в 3.0 для одной обработки используется подключение через ODBC к своей же базе. По словам разработчика, заставить эту обработку работать через new connection() не вышло, а через ODBC всё ок.
Сейчас переношу это на DAX 2009, ни так ни так не выходит.
MS SQL 2008 R2
Подключение ODBC создаётся так:

static void testODBCConnection(Args _args)
{
    ODBCConnection con;
    LoginProperty   LP = new LoginProperty();
    ;
    LP.setServer("Server");
    LP.setDatabase("DB");
    LP.setOther(strfmt("Username=%1;Password=%2", "user", "pwd"));

    con = new ODBCConnection(LP);

}

Выдаётся ошибка: "[Microsoft][Диспетчер драйверов ODBC] Источник данных не найден и не указан драйвер, используемый по умолчанию".
Пароль и пользователь проверены. Вопрос с открытым паролем в коде пока что на втором месте после "заставить это работать". На клиентских машинах DSN создавать не хочется. На сервере DSN имеется, тестовое соединение проходит на ура, но LP.setDSN("DSN") даёт ту же картину.
Если я правильно понимаю, DSN можно вообще не иметь, он создаётся на время
подключения.

Но вообще, конечно, через ODBC к своей базе коннектиться не комильфо, поэтому пытаюсь подключиться через new connection(), но тут своя засада.

    stm = con.createStatement();
    cmd = "begin tran";
    new SqlStatementExecutePermission(cmd).assert();
    stm.executeUpdate(cmd);
    CodeAccessPermission::revertAssert();

    cmd = strfmt("insert LocksTable (purchid, transdate, blocked, dataareaid, recid) " +
               "values ('%1',getdate(),1,'%2', convert(int,@@dbts))", purchid, curext());
    new SqlStatementExecutePermission(cmd).assert();
    stm.executeUpdate(cmd);
    CodeAccessPermission::revertAssert();

/*
обработка
*/

    cmd = "rollback tran";
    new SqlStatementExecutePermission(cmd).assert(); 
    stm.executeUpdate(cmd); // <-- здесь вываливается ошибка SQL
    CodeAccessPermission::revertAssert();

После этого вылета наблюдается следующий глюк: запись в таблице LocksTable остаётся, но удалить её из обозревателя таблиц кнопочкой "удалить запись" не получается - после F5 она остаётся на месте. Запись удаляется только запросом Delete_from.

Есть идеи, что это может быть?

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

Это все где выполняется? На стороне клиента или на стороне сервера? Там где это выполняется соответствующий драйвер ODBC установлен?

[Dark Light]

Для ODBC попробуйте так:

otherStr += "DRIVER={SQL Server}";
otherStr += ";Trusted_Connection=No";
otherStr += strfmt(";SERVER=%1",    ...);
otherStr += strfmt(";DataBase=%1",  ...);
otherStr += strfmt(";UID=%1",       ...);
otherStr += strfmt(";PWD=%1",       ...);
loginProp.setOther(otherStr);

По поводу Connection:
1) почему не использовать стандартные методы con.ttsbegin() и con.ttsabort()?
2) запрос на удаление к БД идет по уникальному ключу. Если ключ содержит текстовое поле, то проблема может быть в Adjustment'е.

Пример: поле Field имеет длину 10 символов. В Аксапте значение в этом поле равно "Код1". В БД оно может быть записано или как "Код1______", или как "______Код1" ("_" - это пробел). Это нужно учитывать при вставке через запрос.

Создайте 2 записи: одну из Аксапты, вторую - через запрос. И посмотрите, есть ли разница в текстовых полях.

[Corel]

Цитата:

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

Это все где выполняется? На стороне клиента или на стороне сервера? Там где это выполняется соответствующий драйвер ODBC установлен?

Класс работает на сервере, тестовый джоб на клиенте. И там и там в параметрах ODBC имеются драйвера SQL Native Client 10.0, и там и там настроен и проверен User DSN

Цитата:

Сообщение от Dark Light

Для ODBC попробуйте так:

otherStr += "DRIVER={SQL Server}";
otherStr += ";Trusted_Connection=No";
otherStr += strfmt(";SERVER=%1",    ...);
otherStr += strfmt(";DataBase=%1",  ...);
otherStr += strfmt(";UID=%1",       ...);
otherStr += strfmt(";PWD=%1",       ...);
loginProp.setOther(otherStr);

Так прошло. То есть, дело в драйвере или TrustedConnection, выходит?

Цитата:

Сообщение от Dark Light

По поводу Connection:
1) почему не использовать стандартные методы con.ttsbegin() и con.ttsabort()?

Попробовал - не то, т.к. в таком случае отменяются и транзакции, создаваемые обработкой (для записи в журнал). То есть, тут смысл такой: запросом к SQL создаются записи в таблице блокировок, чтоб аналогичные одновременно работающие обработки не мешали друг другу, создаются строки журнала, после чего идёт откат транзакции по таблице блокировок.

Насчёт Adjustment - проверю.

[Omeo]

мы используем системный dsn из настроек :

LP.setDSN(_odbcDSN);

полагаю, не надо напоминать (на всякий случай) что 32-х и 64-х битные драйвера ODBC настраиваются в разных местах ...

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

Цитата:

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

Класс работает на сервере, тестовый джоб на клиенте. И там и там в параметрах ODBC имеются драйвера SQL Native Client 10.0, и там и там настроен и проверен User DSN
(...)
То есть, дело в драйвере или TrustedConnection, выходит?

Дело в том, что необходимо явным образом указать имя используемого драйвера. Вот этот фрагмент

Driver = {SQL Server}

В Вашем варианте это будет примерно так

static void testODBCConnection(Args _args)
{
    ODBCConnection con;
    LoginProperty   LP = new LoginProperty();
    ;
    LP.setServer("Server");
    LP.setDatabase("DB");
    LP.setUserName("user");
    LP.setPassword("pwd");
    // Фигураные скобки не обязательны
    LP.setOther("DRIVER={SQL Server}");
// Или если с Windows аутентификацией без указания логина/пароля
//    LP.setOther("DRIVER={SQL Server};Trusted_Connection=Yes");

    con = new ODBCConnection(LP);

}

Кстати, корректный синтаксис строк подключения можно посмотреть вот на этом сайте http://www.connectionstrings.com/

[Dark Light]

Цитата:

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

Попробовал - не то, т.к. в таком случае отменяются и транзакции, создаваемые обработкой (для записи в журнал).

Здесь лучше использовать класс UserConnetion. Он создает отдельное подключение к БД, и тогда данная схема сработает

Connection    con = new UserConnection();

ttsbegin;

con.ttsbegin();

//SQL запрос
...
//SQL запрос

//Обработка в Аксапте
...
//Обработка в Аксапте

con.ttsabort();

ttscommit;

Только тут нужно будет ещё сделать блок try/catch, чтобы в случае ошибки в catch'е вызвать con.ttsabort().

Цитата:

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

То есть, тут смысл такой: запросом к SQL создаются записи в таблице блокировок, чтоб аналогичные одновременно работающие обработки не мешали друг другу, создаются строки журнала, после чего идёт откат транзакции по таблице блокировок.

А из Аксапты доступа к данной таблице нет? Ведь гораздо будет проще в конце операции просто удалять нужную запись из LocksTable.

[Corel]

Нет, это обработка критична к быстродействию (там далеко не одна запись ставится каждый раз), а на запоминании, какие записи были созданы и на удалении их теряется довольно много.

[Dark Light]

Цитата:

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

Нет, это обработка критична к быстродействию (там далеко не одна запись ставится каждый раз), а на запоминании, какие записи были созданы и на удалении их теряется довольно много.

Если у таблицы включить поле createdTransactionId, то delete_from'ом удаляется также быстро, как и при откате транзакции.

delete_from LocksTable
        where LocksTable.createdTransactionId   == appl.lastTransactionIdCreated();

При условии, что записи в LocksTable регулярно чистятся и таблица не разрастается. Иначе, возможно, придется делать индекс по createdTransactionId.