Чтение данных из SQL Server через ODBC. Не работает в 3-х звенке

[sukhanchik]

Всем здравствуйте! Имеется следующая проблема (Ax 3.0SP3):
Хочется считать поле типа дата из скуля через ODBC (варианты Connection, UserConnection или ADO я и так знаю, вопрос конкретно про ODBC). Так вот - из под двухуровневой конфигурации приведенный ниже Job работает нормально.
А вот из-под 3-х уровневой - Axapta рушится при вызове оператора getDate.

PHP код:

    LoginProperty    lp; 
    OdbcConnection   connection; 
    Statement        statement;
    ResultSet        resultSet; 
    str              sSQL;
    ;
    lp = new LoginProperty();
    lp.setDSN('ODBCSQL');
    connection = new OdbcConnection(lp);
    statement  = connection.createStatement();
    sSQL = "SELECT DOCUMENTDATE FROM MYTABLE ";
    resultSet = statement.executeQuery(sSQL);
    resultSet.next();
    info(strfmt('%1', resultSet.getDate(1))); 


Единственный нюанс - AOS - на другом компе.
ODBC 'ODBCSQL' настроена на скуль, аутенфикация виндовая (со скульной те же траблы); указана конкретная база на серваке. Скуль сам локальный, прав хватает :-)
Вопрос - сталкивался ли кто с подобной проблемой ? Дебаггер показывает что все объекты создаются на клиенте - т.е. фактически 3-шка ничем не должна по идее отличаться от двушки

[sukhanchik]

ODBC локальная.
Я полагаю, что такая ситуация могла бы возникнуть - если бы AOS стал бы пытаться достучаться до локального SQL, не смог.. а разработчики ядра не удосужились бы в этом месте сделать лишнюю проверку.
Axapta рушится - с предложением отправить отчет в Microsoft :-)...(Уж можно было бы сразу в MBS :-))

[Oz]

Нарвался абсолютно на те же самые грабли.
Ситуация 1 в 1, за исключением того, что аутентификация сиквельная.
Именно на ODBCConnection, именно на АОСе и падает именно на getDate (после чтения любого поля типа дата из любой таблицы). Что интересно, getString, getInt и getReal в такой же ситуации проходят на ура...

Таки никто не решал такую проблему?

[sukhanchik]

проблема была обойдена
следующий код разрешил неразрешимое

PHP код:

   TransDate docDate;
    str               sSQL;
    boolean     isODBCSQLAccess, isODBCSQLServer;
    OdbcConnection connection;
    LoginProperty lp;
    Statement  statement;
    ResultSet   resultSet;
    #odbcConnectionEntries

    lp = new LoginProperty();
    lp.setDSN('DSN');
    lp.setUsername('login');
    lp.setPassword('password');
    connection = new OdbcConnection(lp);
    statement  = connection.createStatement();
    isODBCSQLAccess = (connection = odbcGetInfoStr(#SQL_DBMS_NAME) == 'ACCESS');
    isODBCSQLServer  = (connection = odbcGetInfoStr(#SQL_DBMS_NAME) == 'Microsoft SQL Server');
    sSQL = 'SELECT *';
    if (isODBCSQLServer)
    {
        sSQL += ', CONVERT(varchar(50), DOCUMENTDATE, 104) AS DOCDATE';
    }
    if (isODBCAccess)
    {
        sSQL += ', DOCUMENTDATE AS DOCDATE';
    }
    resultSet = statement.executeQuery(sSQL);
    docDate = str2date(resultSet.getString(i), 123); 


[sukhanchik]

нельзя сказать что решение идеальное - но внутренние нужды оно удовлетворило

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

Не знаю, что там в 3.0, но в 2.5 - никаких проблем. Правда я подключался не через DSN, а напрямую строку соединения загонял, что-то вроде

LP.setOther("DRIVER=SQL Server;SERVER=MyServer;DataBase=MyBase;Trusted_Connection=Yes");

Возможно, проблема с региональными настройками. Либо в DSN, либо в самом Windows.

[sukhanchik]

Тот факт, что проблема с датой однозначно указывает на корни проблемы - региональные настройки. Однако, очень часто у пользователей стоит русский Windows (в моем случае в т.ч. Access), а тот же SQL Server однако может быть не совсем русский
Предложенный способ (кстати там опечатка - odbcGetInfoStr - это не функция, а метод класса OdbcConnection) - не претендует на универсальность, однако помогает избегать проблем с региональными настройками. Более того, я даже считаю, что разобравшись правильно с региональными настройками, эту проблему скорее всего можно избежать, однако в качестве "быстрого" решения - сия заплатка была придумана, т.к. сия проблема не стоит того, чтобы с ней возиться весь день

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

Предложенный способ - это вообще не решение! Это способ по быстрому обойти проблему не особо с ней разбираясь. Это что же, в каждом запросе надо делать конвертацию даты в строку?

То, что стоит у пользователя, вряд ли имеет принципиальное значение. Надо смотреть настройки DSN и настройки СЕРВЕРА.

Проверь, не стоит ли в настройках DSN "птичка" в пункте

Use regional settings when outputting currency, numbers, dates, and times.

Кстати, если установить связь не через DSN, а через строку подключения глюк остается?