10.04.2008, 13:29 | #1 |
Участник
|
Воспользовался статьей NAV+SQL: Две подружки-хохотушки.
Запрос: Код: cuSQL.GetRes('SELECT id, ItemCode, ResultCount '+ 'FROM InventoryLine ' ,adoRec); В навике 2-е поле (текстовое) берется нормально (нумерация с 0): Код: xlSheet.Range('B'+FORMAT(6+i)).Value := adoRec.Fields.Item(1).Value; [attachment=780:__________.jpg] Сообщение получено с помощью Код: ERROR(adoRec.Fields.Item('ResultCount').Value); Код: ERROR(adoRec.Fields.Item(2).Value); В чем может быть причина? И самое главное, как победить?) |
|
10.04.2008, 13:58 | #2 |
Участник
|
На вопрос ответить, к сожалению, не смогу.
Скажите, пожалуйста, а почему вы не хотите средствами EXCEL+SQL получить результат? Например, написать Stored Procedure или View, а затем в Excel импорт данных из этих объектов? |
|
11.04.2008, 05:01 | #3 |
Участник
|
To randrews
Не совсем понял. Как я понимаю, и хранимка и вьюшка - это аналоги запроса, только используя их можно делать более сложные проверки/выборки (по сути писать программный код). А так и хранимка, и вьюшка, и запрос возвращают набор данных. И в любом случае связка будет Nav + SQL + Excel, ведь и хранимку и вьюшку (и запрос) надо запустить на выполнение и затем используя какие-то средства экспортировать полученные данные в Excel. И вот как из этой связки исключить Nav я и не понял (особенно если учесть, что пользователи собсно на навике и работаеют) А не ипользую SP и View потому, что ПОКА мне хватает возможностей Transact-SQL (т.е. обычных запросов). Может быть у SP или View есть преимущества, о которых мне неизвестно? |
|
11.04.2008, 09:15 | #4 |
Участник
|
Я думал просто вынести в Excel запрос (через импорт данных) и кнопку пользователю Обновить, совсем минуя Nav.
Можно я немного пофлужу в этой теме Я понял, что у Вас простой запрос и способы, предложенные мной не актуальны. Во мне проснулся графоман - зудит в одном месте, что-нибудь написать У нас построена система - большинство отчетов (как ссылки на Excel) вынесены в Outlook в общие папки. Пользователь заходит в папку своего отдела и видит список отчетов. Таким образом, можно: 1. Не тратить сессии Navision (например, менеджерам не нужно ничего редактировать в Navision, им нужно только смотреть, что и реализовано через такие отчеты вне Navision). 2. Быстродействие отчетов с группировками гораздо выше, чем у отчетов Navision. 3. Не тратить объекты Report (хотя это не так существенно) В принципе можно систему ссылок на отчеты Excel организовать и в Navision. Можно написать Stored Procedure с параметрами. Вынести параметры в Excel - тоже реализуется несложным кодом (правда, если параметры не ссылаются на другие справочники). |
|
14.04.2008, 13:29 | #5 |
Участник
|
|
|
16.04.2008, 17:04 | #6 |
Участник
|
а что будет если написать так:
Код: intID := adoRec.Fields.Item('id').Value; MESSAGE('%1', intID); |
|
16.04.2008, 17:37 | #7 |
Участник
|
Конечно, есть. ХП позволяют реализовать сложную логику, например, в отчетах + выполняются на стороне сервера. Вообще, один раз написав отчет с помощью ХП и сделав интерфейс к нему в навижн, вы уже вряд ли будете делать иначе (из своего опыта)
Что касается отчетов в экселе, то тут и впрямь сам NAV не нужен. Нужна ХП, и функционал экселя. ("Импорт внешних данных"). Если интересно, могу показать пример |
|
17.04.2008, 10:03 | #8 |
Участник
|
Цитата:
Цитата:
|
|
17.04.2008, 10:06 | #9 |
Участник
|
само собой. только ХП хранится в откомпилированном виде + для нее составляет оптимальный execution plan с использованием статистики запросов, использования индексов и прочая. И т.д.
|
|
17.04.2008, 10:58 | #10 |
Участник
|
Цитата:
Цитата:
p.s. Интересно Я у randrews спрашивал как это делается, но он промолчал(( |
|
17.04.2008, 11:42 | #11 |
Участник
|
Цитата:
Само по себе это не является преимуществом (имхо). Успешная компиляция гарантирует только отсутствие синтаксических ошибок.
Я думаю так называемый "план выполнения" составляется для каждого запроса перед его первым выполнением (если включено кеширование). Сервер не будет выполнять запрос не отпарсив его и не составив план его выполнения (естественно оптимизированный). Кроме того, ХП - это гарантия защиты данных. Например, у пользователя есть права на выполнение ХП (на выходе какая-то выборка), а на сами таблицы - нет. Можно еще долго рассказывать про них. Цитата:
p.s.
Интересно Я у randrews спрашивал как это делается, но он промолчал(( |
|
17.04.2008, 12:02 | #12 |
Участник
|
Например, так:
в новом файле экселя запускаем импорт внешних данных (Данные-Импорт внешних данных-Импортировать данные...) На выходе получаем на листе объект QueryTable. Он нам и понадобится. Далее, допустим, надо построить отчет, на вход которого подается дата (например, товарные остатки на дату). Дата будет в ячейке $A$1 Тогда пишем следующий макрос и привязываем его к какой-нибудь кнопке на листе: Код: Dim dtmReport As Date Dim strSQL As String dtmReport = Range("$A$1").Value strSQL = "EXECUTE dbo.Proc_Get_Inventory " & "'" & Year(dtmReport) _ & "-" & Month(dtmReport) & "-" & Day(dtmReport) & "'" Range("D14").Select With Selection.QueryTable .RefreshStyle = xlInsertDeleteCells .Connection = Array(Array( _ "ODBC;Description=Navision;DRIVER=SQL Server;SERVER=192.168.1.1;UID=ВАШ ЛОГИН;;APP=Microsoft Data Access Components;WSID=MYWORKSTATION" _ ), Array("OV;DATABASE=MYCOMPANY")) .CommandText = Array(strSQL) .Refresh BackgroundQuery:=False End With |
|
17.04.2008, 12:35 | #13 |
Участник
|
Цитата:
p.s. За пример с excel'ем спасибо. На днях попробую попробовать |
|
17.04.2008, 18:04 | #14 |
Участник
|
Извините. Пропустил мимо тему.
Ну чтоб оправдаться что-нибудь добавлю от себя еще В "свойствах диапозона данных" запроса можно поиграть галками "Включить имена полей", "автоформат данных", "задать ширину столбца".... Тогда после обновления не будут выводиться имена полей из запроса, а будут оставаться ваши, которые вы можете отформатировать на свой "эстетический" вкус А так же не будут ширины столбцов прыгать после обновления, а будут оставаться такими, какими вы их зададите. |
|
18.04.2008, 05:27 | #15 |
Участник
|
|
|