Запуск скрипта из аксапты и получение результата на форму AX

[belugin]

Есть класс Connection который позволяет выполнять прямой sql http://erpkb.info/axapta/доступковнешнимбазам - там примеры с доступом к другим базам но можно так же и со своей.

Я бы сделал временную табличку и скидывал данные туда.

[sukhanchik]

Ну вот по ссылке - есть класс ODBCConnection и UserConnection. ODBCConnection позволяет подключиться под другим пользователем (см пример по ссылке).
UserConnection позволяет не заниматься авторизацией и выполнять все от имени текущего пользователя.

Цитата:

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

Есть класс Connection который позволяет выполнять прямой sql http://erpkb.info/axapta/доступковнешнимбазам - там примеры с доступом к другим базам но можно так же и со своей.

Я бы сделал временную табличку и скидывал данные туда.

В таком виде вполне возможно решить исходную задачу.
Т.е. решать вопрос прав надо на уровне АХ, а не SQL

[YoungPadawan]

Цитата:

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

Ну вот по ссылке - есть класс ODBCConnection и UserConnection. ODBCConnection позволяет подключиться под другим пользователем (см пример по ссылке).
UserConnection позволяет не заниматься авторизацией и выполнять все от имени текущего пользователя.



В таком виде вполне возможно решить исходную задачу.
Т.е. решать вопрос прав надо на уровне АХ, а не SQL

Спасибо. Нужно было просто лучше погуглить. Я не увидел методов setUser() и setPassword() в классе LoginProperty и подумал что в АХ2009 эту возможность убрали. А на самом деле строка подключения формируется по другому https://community.dynamics.com/ax/f/33/t/146719

[YoungPadawan]

Цитата:

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

Спасибо. Нужно было просто лучше погуглить. Я не увидел методов setUser() и setPassword() в классе LoginProperty и подумал что в АХ2009 эту возможность убрали. А на самом деле строка подключения формируется по другому https://community.dynamics.com/ax/f/33/t/146719

Дополню свой ответ. Пользователь на сервере должен быть с проверкой подлинности SQL Server, а не Windows. Может кому-то это очевидно, а я не этом застопорился

[Raven Melancholic]

Цитата:

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

Дополню свой ответ. Пользователь на сервере должен быть с проверкой подлинности SQL Server, а не Windows. Может кому-то это очевидно, а я не этом застопорился

Не обязательно.
Мы можем и с пользователем SQL подключаться, устанавливая строку подключения методом setOther, например, так:

advParms    = 'DRIVER=SQL Server'
                        + '; DATABASE=' + _database
                        + '; SERVER='   + _server + (_port ? ',' + _port : '')
                        + '; UID='      + _userId
                        + '; PWD='      + _password;

loginProperty .setOther(advParms);

[YoungPadawan]

Цитата:

Сообщение от Raven Melancholic

Не обязательно.
Мы можем и с пользователем SQL подключаться, устанавливая строку подключения методом setOther, например, так:

advParms    = 'DRIVER=SQL Server'
                        + '; DATABASE=' + _database
                        + '; SERVER='   + _server + (_port ? ',' + _port : '')
                        + '; UID='      + _userId
                        + '; PWD='      + _password;

loginProperty .setOther(advParms);

А разве я так и не написал что пользователь должен быть SQL, а не Windows?
Или Вы ответили это к тому что можно использовать ODBCConnection + LoginProperty для подключения НЕ под текущим пользователем, а не использовать CCADOConnection?
А пользователя SQL нужно создавать в любом случае?