Проблема с .NET Business Connector (AX 2009)

[nicknk]

Пишется получение данных из аксапты для отдельной системы.
Используется .net business connector.

Есть непонятная проблема следующего характера - не работает стандартный запрос

AxaptaRecord flat = _axapta.Connection.CreateAxaptaRecord("FlatAccountTable");
string q = string.Format("select * from %1 where %1.DataAreaId=='{0}' && %1.AccountNum=='{1}'", _curDataAreaId, accNum);
Console.WriteLine("Query = {0}", q.ToString());                 
flat.ExecuteStmt(q);

Никаких ошибок, ничего, только flat.Found всегда false. Все логины пройдены без проблем.
Экперимент запроса без where тоже выдает пустой результат.

Аналогичный запрос в самой БД дает то что нужно.
Не понимаю где искать косяк

[Alexanderis.ua]

Давно коннектором не пользовался и посмотреть сейчас нет возможности.
Но непонятна конструкция

_axapta.Connection.CreateAxaptaRecord()

Если _axapta это объект типа Microsoft.Dynamics.BusinessConnectorNet.Axapta, то вроде как

_axapta.CreateAxaptaRecord()

Но возможно это всё просто происки вынесенного после 6-ти часов дебага мозга

[nicknk]

Alexanderis.ua, все Вы правильно пишете. Действительно вызывает вопросы =)
Поясняю:
_axapta - это обертка вокруг Microsoft.Dynamics.BusinessConnectorNet.Axapta, упрощающее некоторые утилитарные функции.
А свойство Connection возвращает собственно объект Microsoft.Dynamics.BusinessConnectorNet.Axapta

[S.Kuskov]

RLS на FlatAccountTable не настроено?

Коннектор нужную конфигурацию использует? А то может он на другой AOS смотрит

AxaptaObject SqlSystem = _axapta.Connection.CreateAxaptaObject("SqlSystem");
AxaptaObject loginProperty = SqlSystem.Call("createLoginProperty");
string SQLServer = loginProperty.Call("getServer");
string SQLDatabase = loginProperty.Call("getDatabase");
Console.WriteLine("SQLServer = {0}; SQLDatabase = {1}", SQLServer, SQLDatabase);

[nicknk]

Наверное задам глупый вопрос - RLS это что?
Поясню - я не разработчик на аксапте, а разработчик сторонней системы. мне были предоставлены необходимые запросы по запрошенному перечню данных и дано как получить доступ к этим данным (через .Net BC). Часть запросов работает на ура (даже с join), а вот такой вот примитивный (даже без всяких where) - не работает...
AOS используется тот, что нужен - некоторые выборки работают корректно.

[S.Kuskov]

Record level security (RLS)

Под каким пользователем работает коннектор?
Под каким пользователем проверяли работоспособность запроса в аксапте?

Для разных пользователей аксапта умеет выполнять запрос по разному. Если настроен доступ на уровне записей (RLS) аксапта может добавлять дополнительные фильтры, что бы скрыть данные от пользователей, которым они не предназначены.

[_scorp_]

RLS по умолчанию на обычных селектах не включается, в отличие от Query. Так что думаю, что дело не в этом. Советую Вам все запросы строить в аксапте через Query. Сделать класс со статическим методом, который вовращает уже нужный Вам квери. Дергайте этот метод через BC. Создавйте quryRun и пробегайтесь по query. В общем я к тому, что вся логика должна быть на стороне AX, а через BC Вы просто будете дергать эту логику.

[nicknk]

Цитата:

Сообщение от S.Kuskov

RLS на FlatAccountTable не настроено?

Коннектор нужную конфигурацию использует? А то может он на другой AOS смотрит

AxaptaObject SqlSystem = _axapta.Connection.CreateAxaptaObject("SqlSystem");
AxaptaObject loginProperty = SqlSystem.Call("createLoginProperty");
string SQLServer = loginProperty.Call("getServer");
string SQLDatabase = loginProperty.Call("getDatabase");
Console.WriteLine("SQLServer = {0}; SQLDatabase = {1}", SQLServer, SQLDatabase);

Спасибо за код - проверил! Еще раз подтвердилось, что все нормально, все как и должно быть.

Цитата:

Сообщение от S.Kuskov

Под каким пользователем работает коннектор?
Под каким пользователем проверяли работоспособность запроса в аксапте?

Для разных пользователей аксапта умеет выполнять запрос по разному. Если настроен доступ на уровне записей (RLS) аксапта может добавлять дополнительные фильтры, что бы скрыть данные от пользователей, которым они не предназначены.

В аксапте работоспособность не проверялась, поскольку с самой аксаптой не работаем, только через BC.
Запрос проверялся напрямую в БД.
Повторюсь - часть запросов через BC (к другим таблицам) работает нормально. С этой таблицей целая проблема - даже выборка всей таблицы (select * from tablename) дает пустой результат.

_scorp_, спасибо за совет, уже видел такие предложения. Да, наверное соглашусь с Вами, что это более верный путь.
но в моем случае это неприменимо по ряду причин:
1 Нет опыта работы в аксапте и нет разработчиков на аксапте
2 Сама система на аксапте разрабатывалась другими разработчиками и была договоренность, что мы в саму аксапту не лезем.

[_scorp_]

Думаю проблема в том, что вы подключаетесь не к той компании. Проверьте в настройках пользователя, под которым Вы подключаетесь компанию по умолчанию и компанию в конфигурационном файле (если она там указана). Либо в методе LogonAs, при подключении через BC не ту компанию указываете. Посмотрите через SQL профайлер с каким фильтром по dataAreaId идут запросы к БД.

[nicknk]

Цитата:

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

Думаю проблема в том, что вы подключаетесь не к той компании. Проверьте в настройках пользователя, под которым Вы подключаетесь компанию по умолчанию и компанию в конфигурационном файле (если она там указана). Либо в методе LogonAs, при подключении через BC не ту компанию указываете. Посмотрите через SQL профайлер с каким фильтром по dataAreaId идут запросы к БД.

Да, действительно, сменил компанию в LogonAs на ту, которую указывал в запросе WHERE для поля DataAreaID - и все сразу нашлось.
Если я правильно понимаю, получается, что Аксапта сама добавляет фильтрацию по этому полю исходя из указанной в LogonAs и нет необходимости указывать его в запросах?
Тогда возникает вопрос - а можно ли каким-то образом указать LogonAs так, что бы работать с несколькими компаниями? У меня есть часть запросов, которые осуществляют join по другой компании... Правильно ли будет в LogonAs не указывать компанию вообще(пустую строку передавать)?

[S.Kuskov]

Цитата:

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

Тогда возникает вопрос - а можно ли каким-то образом указать LogonAs так, что бы работать с несколькими компаниями? У меня есть часть запросов, которые осуществляют join по другой компании... Правильно ли будет в LogonAs не указывать компанию вообще(пустую строку передавать)?

http://blogs.msdn.com/b/x/archive/20...e-browser.aspx

[_scorp_]

Тяжело Вам будет без программиста аксапты Компанию всегда указывайте. Если хотите выбирать данные из нескольких компаний, то используйте в запросах crosscompany (Если у Вас конечно AX, с версией не ниже 2009).

[nicknk]

S.Kuskov, _scorp_, очень помогли! Большое спасибо!

_scorp_, да я уже понял, что не все так просто, как выглядело изначально (получить sql запросы, реализовать их через Аксапту, сделать предметную обвязку и пару WCF-сервисов)

Поэтому есть вопрос общий - где взять нормальное описание команд для запросов на X++ - потому что довольно много пришлось ковыряться, что бы выяснить, почему не компилятся запросы с AND и что его нужно заменять на &&.
Сейчас столкнулся с тем, что не работает TOP 1...
И абсолютно не понимаю, как вызывать встроенные процедуры SQL-сервера.
И все через .net BC

[S.Kuskov]

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

Если вы точно знаете какой SQL запрос вам нужно выполнить, не проще ли работать не через сервер приложения (AOS), а напрямую c базой данных? К стати говоря, "вызывать встроенные процедуры SQL-сервера" только так и получится

"TOP 1" = "firstOnly"

[nicknk]

Получилось как обычно - простая задача, которая теоретически должна была решаться красиво требует извращения: часть запросов через БД, часть через BC - есть несколько запросов, для которых необходимо использовать статические методы аксапты, потому что через БД получается очень сложный многоэтажный запрос.

Спасибо за помощь, очень здорово помогли!