Как из Axapta загрузить (выполнить) хранимую процедуру

[Buba]

Пытаюсь отыскать в АОТ какой-нибудь класс, позволяющий работать с хранимыми процедурами SQL Server - пока безуспешно. Есть ли такая воозможность вообще и если да, то как ее реализовать в Axapta?

[Alex_K]

А Вы загляните в базу Аксапты через MS SQL Enterprise Manager - там хоть одна SP есть? Применение SP официально не рекомендуется Navision. Так что придется разбираться самому. Или многоуважаемый коллективный разум что-нибудь подскажет из собственного опыта...

[Garic]

Например так:

PHP код:

    Connection  connection;
    Statement   stmt;
    ResultSet   resultSet;
    str         sqlS;
    ;

    connection = new Connection();
    stmt = connection.createStatement();

    sqlS = 'execute AxTest.bmssa.test';
    resultSet = stmt.executeQuery(sqlS);
    while (resultSet.next())
    {
        info (resultSet.getString(1));
    } 


getString(1) - первая колонка.
P.S. Если команду getString выполнить дважды возникнет ошибка. Т.е. так делать нельзя:

PHP код:

    while (resultSet.next())
    {
        info (resultSet.getString(1));
        info (resultSet.getString(1));
    } 


[Buba]

В папке Stored Procedures их 30 штук
За код благодарю! Спасибо!

[Alex_K]

Во-первых, те SP, что имеются, системные и к Аксапте отношения не имеют, специально посмотрел в базы 2.5 и 3.0
Во-вторых, Игорь, а User-Defined Function от SQL 2000 не использовали?

[Garic]

Цитата:

Во-первых, те SP, что имеются, системные и к Аксапте отношения не имеют, специально посмотрел в базы 2.5 и 3.0

Ну мало-ли. Может нужно запустить свою процедуру.

Цитата:

Во-вторых, Игорь, а User-Defined Function от SQL 2000 не использовали?

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

[Buba]

Системные значит системные, 31 первая будет не системной.

Господа, а почему так настоятельно не рекомендуется использовать хранимые процедуры? Где можно подчерпнуть информацию-объяснения или аргументы?

Может это связано с тем, что возможность прямого доступа к SQL Server, а не средствами Axapta, может привести к нарушению структуры БД (например, неправильная работа с RecId).

[Alex_K]

Цитата:

Изначально опубликовано Buba

Господа, а почему так настоятельно не рекомендуется использовать хранимые процедуры? Где можно подчерпнуть информацию-объяснения или аргументы?

Может это связано с тем, что возможность прямого доступа к SQL Server, а не средствами Axapta, может привести к нарушению структуры БД (например, неправильная работа с RecId).

Примерно так. Основная мотивировка - что-то вроде: "Мы не сможем гарантировать работоспособность Ваших доработок после установки обновлений" и "Это не соответствует идеологии системы".

Однозначно, на мой взгляд, что SP или UDF в Аксапте стоит использовать только для чтения.

[mazzy]

Ну и recID, конечно.

На самом деле использование хранимых процедур сильно осложнит вам жизнь в будущем, когда вы будете ставить СП, переходиьт на новую версию или на другую базу данных. Стоимость будущих сложностей с лихвой может перекрыть преимущества от текущего использования хранимых процедур.

Второй аспект. Аксапта сама занимается кэшированием данных. Хранимые процедуры скорее всего этот механизм учитывать не будут. Что чревато потерей данных.

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

[Андре]

Цитата:

Ну мало-ли. Может нужно запустить свою процедуру.

Как правило, такой подход применяется при импорте в Аксапту данных из различных внешних систем.
В сети есть множество разнородных источников данных, подключенных к SQL Server как linked сервера. На SQL Server'е пишется SP, которая из всех этих источников данных выбирает нужную новую информацию, как-то обрабатывает ее и заносит в специальную табличку. Пользователь Аксапты с нужной ему периодичностью жмет клавишу в Аксапте, запускается эта хранимая процедура, все данные собираются в специальную табличку, откуда затем самой Аксаптой (с помощбю того же Connection) растаскиваются по необходимым таблицам.

[Андре]

Цитата:

Может это связано с тем, что возможность прямого доступа к SQL Server, а не средствами Axapta, может привести к нарушению структуры БД (например, неправильная работа с RecId).

Дам и я свою ссылочку:

http://www.adem.karavaevo.ru/Axapta/Article1.html

[mazzy]

Цитата:

Изначально опубликовано Alex_K
"Это не соответствует идеологии системы".

Точно. А идеология очень простая: Вся логика находится в одном месте - в Аксапте.
Такой подход сильно упрощает и удешеляет сопровождение.
Для выполнения операций на серверной стороне используется AOS, а не хранимые процедуры.

Конечно бывают случаи. Например, Андре, говорит о импорте. Но я бы и к таким случаям относился с осторожностью, поскольку validate проходит непонятно по каким правилам... И что будет с целостностью базы после импорта внешними (не Аксаптовскими) средствами - вопрос.

[Buba]

Андре описал именно тот случай, над которым мы работаем, а именно импорт данных.

Вопрос к mazzy.
Если все-таки следовать рекомендациям использовать для импорта исключительно средства Аксапта с тем, чтобы не иметь проблем в будующем, то какими именно?

[Андре]

Цитата:

Конечно бывают случаи. Например, Андре, говорит о импорте. Но я бы и к таким случаям относился с осторожностью, поскольку validate проходит непонятно по каким правилам... И что будет с целостностью базы после импорта внешними (не Аксаптовскими) средствами - вопрос.

По моему ты меня не совсем понял. Или я что-то не понимаю

Хранимая процедура просто собирает информацию из различных источников - dbf-файлы, excel'евские файлы, текстовые файлы, другие базы данных на SQL Server'е, обабатывает их, и помещает в одну таблицу. Здесь имеется в виду не Аксаптовская таблица, а просто таблица на SQL Server'е.
Затем уже Аксапта лезет в эту таблицу (например с помощью ADO) берет оттуда данные и САМА помещает их в свои Аксаптовские таблицы.

Так что с validate здесь все в порядке.

[Alex_K]

Цитата:

Изначально опубликовано Андре


Хранимая процедура просто собирает информацию из различных источников - dbf-файлы, excel'евские файлы, текстовые файлы, другие базы данных на SQL Server'е, обабатывает их, и помещает в одну таблицу. Здесь имеется в виду не Аксаптовская таблица, а просто таблица на SQL Server'е.
Затем уже Аксапта лезет в эту таблицу (например с помощью ADO) берет оттуда данные и САМА помещает их в свои Аксаптовские таблицы.

Так что с validate здесь все в порядке.

А зачем так сложно? Если буферная таблица более ни для чего не используется, только залил данные - разбросал по другим таблицам - подмел за собой, зачем городить огород с ADO? Кстати, свойство таблицы "Temporary" для этого не подойдет?

[Андре]

Цитата:

А зачем так сложно?

Потому, что в SP происходит много такой работы, которая плохо реализуется в Аксапте. Под "плохо" я имею в виду то, что часть вещей в ней решается не красиво (так как она для этого не предназначена), а часть вещей работает очень медленно (так как на T-SQL я могу составить запрос, который по быстродействию далеко обгонит запросы, генерируемые Аксаптой).

[Alex_K]

Ты не понял...
Я спрашивал о возможности заливать данные из SP не в отдельную таблицу MS SQL, а в таблицу Аксапты, специально для транзита данных предназначенную, чтобы не заморачиваться с ADO и т.п.

[Андре]

Цитата:

Я спрашивал о возможности заливать данные из SP не в отдельную таблицу MS SQL, а в таблицу Аксапты

Сложности с генерацией recId из вне Акспты.

Хотя вполне решаемые - см. мою ссылку выше.

[mazzy]

Alex_k, Андре, понял. Согласен.
Хотя это опять программирование....

Цитата:

Изначально опубликовано Buba
Если все-таки следовать рекомендациям использовать для импорта исключительно средства Аксапта с тем, чтобы не иметь проблем в будующем, то какими именно?

Хм... смотря кто спрашивает, если такой вопрос задает пользователь, то использовать иморт из экселя или из текстового файла. www.axapta.mazzy.ru/hints/import/

Если такой вопрос задает программист, то наверное способ, предложенный Andre. Где то готовим данные, а в Аксапту затягиваем job'ом.


Есть еще один способ для программиста. Он мне нравится больше. Но на самом деле это дело вкуса. В Аксапте есть классы, которые могут читать данные из ODBC. Посмотрите на форму CCDataLinkTable и все с ней связанное. Правда этот модуль идет в дорогой лицензии модуля Стратегическое управление. Но посмотреть на этот инструмент все равно стоит.