08.05.2003, 09:06 | #1 |
Участник
|
Как из Axapta загрузить (выполнить) хранимую процедуру
Пытаюсь отыскать в АОТ какой-нибудь класс, позволяющий работать с хранимыми процедурами SQL Server - пока безуспешно. Есть ли такая воозможность вообще и если да, то как ее реализовать в Axapta?
|
|
08.05.2003, 09:25 | #2 |
Участник
|
А Вы загляните в базу Аксапты через MS SQL Enterprise Manager - там хоть одна SP есть? Применение SP официально не рекомендуется Navision. Так что придется разбираться самому. Или многоуважаемый коллективный разум что-нибудь подскажет из собственного опыта...
|
|
08.05.2003, 09:26 | #3 |
NavAx
|
Например так:
PHP код:
P.S. Если команду getString выполнить дважды возникнет ошибка. Т.е. так делать нельзя: PHP код:
__________________
С уважением, Игорь Ласийчук. |
|
|
За это сообщение автора поблагодарили: kashperuk (3). |
08.05.2003, 09:37 | #4 |
Участник
|
В папке Stored Procedures их 30 штук
За код благодарю! Спасибо! |
|
08.05.2003, 09:50 | #5 |
Участник
|
Во-первых, те SP, что имеются, системные и к Аксапте отношения не имеют, специально посмотрел в базы 2.5 и 3.0
Во-вторых, Игорь, а User-Defined Function от SQL 2000 не использовали? |
|
08.05.2003, 10:10 | #6 |
NavAx
|
Цитата:
Во-первых, те SP, что имеются, системные и к Аксапте отношения не имеют, специально посмотрел в базы 2.5 и 3.0
Цитата:
Во-вторых, Игорь, а User-Defined Function от SQL 2000 не использовали?
Полезным бывает таким образом выполнять запрос код которого заранее неизвестен. Конечно в этом случае можно пользоваться командой runbuf, но она работает медленней.
__________________
С уважением, Игорь Ласийчук. |
|
08.05.2003, 10:22 | #7 |
Участник
|
Системные значит системные, 31 первая будет не системной.
Господа, а почему так настоятельно не рекомендуется использовать хранимые процедуры? Где можно подчерпнуть информацию-объяснения или аргументы? Может это связано с тем, что возможность прямого доступа к SQL Server, а не средствами Axapta, может привести к нарушению структуры БД (например, неправильная работа с RecId). |
|
08.05.2003, 10:32 | #8 |
Участник
|
Цитата:
Изначально опубликовано Buba
Господа, а почему так настоятельно не рекомендуется использовать хранимые процедуры? Где можно подчерпнуть информацию-объяснения или аргументы? Может это связано с тем, что возможность прямого доступа к SQL Server, а не средствами Axapta, может привести к нарушению структуры БД (например, неправильная работа с RecId). Однозначно, на мой взгляд, что SP или UDF в Аксапте стоит использовать только для чтения. |
|
08.05.2003, 10:37 | #9 |
Участник
|
Ну и recID, конечно.
На самом деле использование хранимых процедур сильно осложнит вам жизнь в будущем, когда вы будете ставить СП, переходиьт на новую версию или на другую базу данных. Стоимость будущих сложностей с лихвой может перекрыть преимущества от текущего использования хранимых процедур. Второй аспект. Аксапта сама занимается кэшированием данных. Хранимые процедуры скорее всего этот механизм учитывать не будут. Что чревато потерей данных. Третий аспект. На самом деле с запросами у Аксапты более-менее хорошо. Желание использовать хранимые процедуры, как правило, возникает из-за неправильного или неполного использования стандартных возможностей. А это значит, что ресурсы тратятся зря, не на достижение результата, а на борьбу за победу рабочего класса (за хранимые процедуры ). Конечно бывают исключения. Но судя по вопросу, это не тот случай. |
|
08.05.2003, 10:41 | #10 |
Moderator
|
Цитата:
Ну мало-ли. Может нужно запустить свою процедуру.
В сети есть множество разнородных источников данных, подключенных к SQL Server как linked сервера. На SQL Server'е пишется SP, которая из всех этих источников данных выбирает нужную новую информацию, как-то обрабатывает ее и заносит в специальную табличку. Пользователь Аксапты с нужной ему периодичностью жмет клавишу в Аксапте, запускается эта хранимая процедура, все данные собираются в специальную табличку, откуда затем самой Аксаптой (с помощбю того же Connection) растаскиваются по необходимым таблицам. |
|
08.05.2003, 10:46 | #11 |
Moderator
|
Цитата:
Может это связано с тем, что возможность прямого доступа к SQL Server, а не средствами Axapta, может привести к нарушению структуры БД (например, неправильная работа с RecId).
http://www.adem.karavaevo.ru/Axapta/Article1.html |
|
08.05.2003, 10:50 | #12 |
Участник
|
Цитата:
Изначально опубликовано Alex_K
"Это не соответствует идеологии системы". Такой подход сильно упрощает и удешеляет сопровождение. Для выполнения операций на серверной стороне используется AOS, а не хранимые процедуры. Конечно бывают случаи. Например, Андре, говорит о импорте. Но я бы и к таким случаям относился с осторожностью, поскольку validate проходит непонятно по каким правилам... И что будет с целостностью базы после импорта внешними (не Аксаптовскими) средствами - вопрос. |
|
08.05.2003, 11:07 | #13 |
Участник
|
Андре описал именно тот случай, над которым мы работаем, а именно импорт данных.
Вопрос к mazzy. Если все-таки следовать рекомендациям использовать для импорта исключительно средства Аксапта с тем, чтобы не иметь проблем в будующем, то какими именно? |
|
08.05.2003, 11:13 | #14 |
Moderator
|
Цитата:
Конечно бывают случаи. Например, Андре, говорит о импорте. Но я бы и к таким случаям относился с осторожностью, поскольку validate проходит непонятно по каким правилам... И что будет с целостностью базы после импорта внешними (не Аксаптовскими) средствами - вопрос.
Хранимая процедура просто собирает информацию из различных источников - dbf-файлы, excel'евские файлы, текстовые файлы, другие базы данных на SQL Server'е, обабатывает их, и помещает в одну таблицу. Здесь имеется в виду не Аксаптовская таблица, а просто таблица на SQL Server'е. Затем уже Аксапта лезет в эту таблицу (например с помощью ADO) берет оттуда данные и САМА помещает их в свои Аксаптовские таблицы. Так что с validate здесь все в порядке. |
|
08.05.2003, 11:27 | #15 |
Участник
|
Цитата:
Изначально опубликовано Андре
Хранимая процедура просто собирает информацию из различных источников - dbf-файлы, excel'евские файлы, текстовые файлы, другие базы данных на SQL Server'е, обабатывает их, и помещает в одну таблицу. Здесь имеется в виду не Аксаптовская таблица, а просто таблица на SQL Server'е. Затем уже Аксапта лезет в эту таблицу (например с помощью ADO) берет оттуда данные и САМА помещает их в свои Аксаптовские таблицы. Так что с validate здесь все в порядке. |
|
08.05.2003, 11:51 | #16 |
Moderator
|
Цитата:
А зачем так сложно?
|
|
08.05.2003, 11:59 | #17 |
Участник
|
Ты не понял...
Я спрашивал о возможности заливать данные из SP не в отдельную таблицу MS SQL, а в таблицу Аксапты, специально для транзита данных предназначенную, чтобы не заморачиваться с ADO и т.п. |
|
08.05.2003, 12:04 | #18 |
Moderator
|
Цитата:
Я спрашивал о возможности заливать данные из SP не в отдельную таблицу MS SQL, а в таблицу Аксапты
Хотя вполне решаемые - см. мою ссылку выше. |
|
08.05.2003, 22:43 | #19 |
Участник
|
Alex_k, Андре, понял. Согласен.
Хотя это опять программирование.... Цитата:
Изначально опубликовано Buba
Если все-таки следовать рекомендациям использовать для импорта исключительно средства Аксапта с тем, чтобы не иметь проблем в будующем, то какими именно? Если такой вопрос задает программист, то наверное способ, предложенный Andre. Где то готовим данные, а в Аксапту затягиваем job'ом. Есть еще один способ для программиста. Он мне нравится больше. Но на самом деле это дело вкуса. В Аксапте есть классы, которые могут читать данные из ODBC. Посмотрите на форму CCDataLinkTable и все с ней связанное. Правда этот модуль идет в дорогой лицензии модуля Стратегическое управление. Но посмотреть на этот инструмент все равно стоит. |
|