Класс ODBCConnection

[sukhanchik]

Из моих наблюдений ...
Что неудобно / нужно помнить
1. При конструировании запроса нельзя забывать добавлять условие фильтрации компании (Аксапта ведь сама в X++ автоматически добавляет это условие). Если в системе используются виртуальные компании, то в этом случае в определенных таблицах поле dataareaid будет в себе содержать не идентификатор текущей компании, а идентификатор виртуальной компании. Конечно об этом нужно помнить только при построении запросов внутри одной компании.

2. Имя поля/таблицы в AOT вообще говоря отличается от соответствующих имен в БД. Правда это касается только таблиц/полей с именем, длиннее 30 символов (в частности у MS SQL Server) - однако такие названия встречаются.
В этом случае корректнее будет за каждым названием лезть в табличку SQLDictionary - которая хранит соответствие название в АОТ названиям в БД.

3. Считать поле результата выборки (это класс ResultSet) можно только один раз и только по возрастанию порядка следования. Т.е. после считывания поля3 - поля1, 2 и 3 считать уже нельзя. Плюс возможность передвижения по курсору только вперед. Сюда же можно отнести невозможность при считывании данных обращаться по имени а не по номеру поля.

4. Ну и наконец любимая заморочка с датами. Если класс исполняется на клиенте и региональные настройки клиента отличаются от региональных настроек сервера - то для даты метод getString не прокатит - тк с точки зрения сервера это дата, однако метод getDate также не прокатит - т.к. он не сможет преобразовать серверную дату в клиентскую.

Если это возможно (в Вашем случае) - я бы порекомендовал подключение через ADO. (Классы ссADO*). При их использовании пункты 3 и 4 устраняются.

[AndyD]

Цитата:

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

2. Имя поля/таблицы в AOT вообще говоря отличается от соответствующих имен в БД. Правда это касается только таблиц/полей с именем, длиннее 30 символов (в частности у MS SQL Server) - однако такие названия встречаются.
В этом случае корректнее будет за каждым названием лезть в табличку SQLDictionary - которая хранит соответствие название в АОТ названиям в БД.

Имена таблиц и полей в б/д можно доставать с помощью классов DictTable и DictField

dictTable.name(DbBackend::Sql);
dictTable.fieldName(fieldnum(...), DbBackend::Sql);
dictField.name(DbBackend::Sql);

[Gustav]

Цитата:

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

Если это возможно (в Вашем случае) - я бы порекомендовал подключение через ADO. (Классы ссADO*).

Ползая по Сети, наткнулся на приятный материал:

"Примеры подключения различных Баз Данных через ADO" (в том числе через драйверы ODBC)
http://www.webmasterpro.com.ua/news339.html

Цитата:

Данный материал содержит примеры создания строк ADO connection для различных типов часто используемых Баз Данных, например: ODBC DSN, ODBC DSN-Less, OLE DB Provider, MS Remote, Oracle, Excel, FoxPro и т.д.

Среди прочего интересного говорится о том, что к Excel можно достучаться по ADO посредством "аксесного" провайдера Microsoft.Jet.OLEDB:

Цитата:

Примечание: You can also open an Excel spreadsheet using the "OLE DB Provider for Microsoft Jet"
oConn.Open "Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=somepathexpenses.xls;" & _
"Extended Properties=""Excel 8.0;HDR=Yes;"";"
Where "HDR=Yes" means that there is a header row in the cell range
(or named range), so the provider will not include the first row of the
selection into the recordset. If "HDR=No", then the provider will include
the first row of the cell range (or named ranged) into the recordset.

а также о том, как организовать доступ к защищенной базе Access (приводится следующая ссылка на Microsoft):

"How To Open a Secured Access Database in ADO Through OLE DB"
http://support.microsoft.com/kb/q191754/

P.S.
Если кто-то будет играться с темой "ADO+Excel", то вот в дополнение крайне полезная ссылка на ветку "Быстрый Excel":
http://www.axforum.info/forums/showt...2677#post22677 ,

в которой упоминается тема "How To Use ADO with Excel Data from Visual Basic or VBA":
http://support.microsoft.com/kb/q257819/

[Gustav]

Цитата:

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

4. Ну и наконец любимая заморочка с датами. Если класс исполняется на клиенте и региональные настройки клиента отличаются от региональных настроек сервера - то для даты метод getString не прокатит - тк с точки зрения сервера это дата, однако метод getDate также не прокатит - т.к. он не сможет преобразовать серверную дату в клиентскую.

Пришлось неприятно столкнуться с getDate. Разрулил ситуацию использованием преобразования даты в строку в самом SQL-запросе и далее обратным преобразованием уже в Аксапте. Для Oracle выглядит примерно так:

    Statement S;
    ResultSet resultSet;
    TransDate tDate;
    ......

    resultSet = S.executeQuery(
        "SELECT TO_CHAR(TransDate, 'DD.MM.YYYY') AS td FROM Table1");

    while (resultSet.next())
    {
        tDate = str2date(resultSet.getString(1), 123);
        ......
    }