|
Stored procedure exceeds 32 k limit...
|
|||
---|---|---|---|
#18+
Размер SQL процедуры начал превышать максамально допустимый размер в 32К. Как советовал NewYear буду разбивать её на две поменьше, вызывая из С программы, оформленной как ХП. Т.е. Код: plaintext 1. 2. 3. 4.
,где MYLIB.Program - прога на Си. Правильно ли это? Можно ли написать процедуру на SQL'e, где вызывались бы другие процедуры? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2003, 17:19 |
|
Stored procedure exceeds 32 k limit...
|
|||
---|---|---|---|
#18+
>Правильно ли это? правильно. >Можно ли написать процедуру на SQL'e, где вызывались бы другие процедуры? можно. не важно, на чем написана процедура. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2003, 17:28 |
|
Stored procedure exceeds 32 k limit...
|
|||
---|---|---|---|
#18+
Помоему не важно на каком языке написана процедура это на 390. DB2 LUW SQL процедура не может вызывать Java. Помоему.... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2003, 19:26 |
|
Stored procedure exceeds 32 k limit...
|
|||
---|---|---|---|
#18+
ну, разве что Java. (не пишу прoцедур на java) =============================================== на OS/400 у меня вообще получилось написать на sql, а заявить как language С parameter style db2sql. оч удобно, когда нужно перенести процедуру на машину, где нет компилятора. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2003, 19:33 |
|
Stored procedure exceeds 32 k limit...
|
|||
---|---|---|---|
#18+
В таком случае появляется ещё одна проблема: Nesting CALL Statements A program that is executing as a procedure, a user-defined function, or a trigger can issue a CALL statement. When a procedure, user-defined function, or trigger calls a procedure, user-defined function, or trigger, the call is considered to be nested. There is no limit on how many levels procedures and functions can be nested, but triggers can only be nested up to 300 levels deep. If a procedure returns any query result sets, the result sets are returned to the caller of the procedure. If the SQL CALL statement is nested, the result sets are visible only to the program that is at the previous nesting level. For example, if a client program calls procedure PROCA, which in turn calls procedure PROCB. Only PROCA can access any result sets that PROCB returns; the client program has no access to the query result sets. как передать "внутренний" ResultSet программе вызвавшей процедуру с вложенным вызовом другой процедуры? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2003, 16:18 |
|
Stored procedure exceeds 32 k limit...
|
|||
---|---|---|---|
#18+
риман, на какой это платформе? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2003, 16:28 |
|
Stored procedure exceeds 32 k limit...
|
|||
---|---|---|---|
#18+
Платформа: OS/400 v5r2m0 Вызов процедуры происходит из ХП на SQL. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.09.2003, 11:41 |
|
Stored procedure exceeds 32 k limit...
|
|||
---|---|---|---|
#18+
да напиши всю процедуру на си. там нет никакого ограничения на длину исходника, и кода, как показывает практика получается меньше. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.09.2003, 19:52 |
|
Stored procedure exceeds 32 k limit...
|
|||
---|---|---|---|
#18+
По - видимому так и придется сделать (вот мля :| ). Спасибо за ответы. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2003, 11:23 |
|
Stored procedure exceeds 32 k limit...
|
|||
---|---|---|---|
#18+
Но ведь (по крайней мере, на DB2 UDB) в C-процедурах и функциях [была] невозможной работа с DECIMAL, а ведь именно в полях такого типа хранят деньги? Как там жабные процедуры - они уже работоспособны или все еще нет? (Последний раз я проверял их в DB2 v5 - чудовищно глючили тогда). ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2003, 15:26 |
|
Stored procedure exceeds 32 k limit...
|
|||
---|---|---|---|
#18+
Victor Metelitsa int counter; decimal (15,7) money; AS/400 вообще вещь забавная. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2003, 15:38 |
|
Stored procedure exceeds 32 k limit...
|
|||
---|---|---|---|
#18+
Что, неужели в си нельзя работать с DECIMAL? ______________________________________ чем дальше в лес тем больше дров... (с) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2003, 15:42 |
|
Stored procedure exceeds 32 k limit...
|
|||
---|---|---|---|
#18+
на аэске можно ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2003, 15:52 |
|
Stored procedure exceeds 32 k limit...
|
|||
---|---|---|---|
#18+
2 Victor Metelitsa >Как там жабные процедуры - они уже работоспособны или все еще нет? >(Последний раз я проверял их в DB2 v5 - чудовищно глючили тогда). У меня вполне работоспособны (в восьмой версии). Не глючат и не тормозят(у меня, по крайней мере). Процедуры правда не очень большие. В основном на массовые изменения цен и прочей лабуды, где они гораздо эффективней динамических запросов. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2003, 16:04 |
|
Stored procedure exceeds 32 k limit...
|
|||
---|---|---|---|
#18+
Чем эффективнее? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2003, 07:06 |
|
Stored procedure exceeds 32 k limit...
|
|||
---|---|---|---|
#18+
Эффективнее по скорости. Поскольку, как я понимаю, в ХП запросы компилированные и план уже построен. Во всяком случае некоторое время существовало два способа изменения данных, пока я дописывал процедуры, и ощущения после перехода от запросов к процедурам исключительно положительные. Повторюсь - это только в контексте изменения больших объемов данных на больших таблицах с небольшим или вовсе никаким приростом за день. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2003, 07:31 |
|
Stored procedure exceeds 32 k limit...
|
|||
---|---|---|---|
#18+
Так я и думал - "ощущения". Для полноты картины еще скажите, что эти SP работают через JDBC. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2003, 10:07 |
|
Stored procedure exceeds 32 k limit...
|
|||
---|---|---|---|
#18+
Ваш ответ наводит на мысль, что Вы не знаете разницы между static SQL и dynamic SQL, а также не меряли время прекомпиляции запроса. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2003, 10:14 |
|
Stored procedure exceeds 32 k limit...
|
|||
---|---|---|---|
#18+
Про ощущения - замерялось время. Я писал для этого тестовые примеры, чтобы убедить других членов команды в необходимости процедур. Сейчас не приведу конкретных цифр, но время сокращалось существенно. Применялось SQLJ. Если можно подробнее про разницу между static и dynamic? Хотя-бы применительно к вышесказанному. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2003, 14:55 |
|
Stored procedure exceeds 32 k limit...
|
|||
---|---|---|---|
#18+
"Ощущения" - это противоположность измерениям. Если некий факт имеет место, желательно иметь скрипт для его воспроизведения и выяснения причин. Лично мне этот факт кажется невероятным. Да, статический SQL - тот, что заранее прекомпилируется и планы хранятся в базе, в противоположность динамическому. Просьба не путать с embedded SQL. Embedded SQL может быть и динамическим, а программы, использующие static SQL, не обязаны использовать Embedded SQL. Примеры: 1) VA Smalltalk, самостоятельно генерирующий пакеты; 2) см. хелп по утилите db2cap "Binds a capture file to generate one or more static packages. A capture file is generated during a static profiling session of a CLI/ODBC/JDBC application, and contains SQL statements that were captured during the application run. This utility processes the capture file so that it can be used by the CLI/ODBC/JDBC driver to execute static SQL for the application" Далее, статический SQL никак не связан только с хранимыми процедурами. Его могут использовать и хранимые процедуры, и обычные клиентские программы. А могут и не использовать. Поэтому заявление "хранимые процедуры гораздо эффективнее динамических запросов" не имеет смысла. Смысл мог быть в заявлениях наподобие "статический SQL гораздо эффективнее динамического в таких-то условиях" или "хранимые процедуры выполняют запросы эффективнее обычных приложений" - но так ли это? Например, в чем разница между выполнением запроса посредством статического SQL и динамического? Во времени компиляции? Но обычно это занимает доли секунды. Скорее всего это сказалось бы на коротких запросах, выполняемых в цикле. Но на это есть кеширование планов. Запрос, конечно, выполняет не хранимая процедура, а СУБД - какая ей разница, кто запрос послал. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2003, 11:00 |
|
Stored procedure exceeds 32 k limit...
|
|||
---|---|---|---|
#18+
2 Victor Metelitsa: Возможно показалось что я имею ввиду запросы из ХП всегда эффективнее запросов из обычных программ. Если это так то я беру слова обратно. Данное ускорение работы имело место в моем частном случае от чего я не отказываюсь и здесь именно ХП имели выигрыш перед другими способами изменения данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2003, 14:35 |
|
Stored procedure exceeds 32 k limit...
|
|||
---|---|---|---|
#18+
А за счет чего был выигрыш? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2003, 17:15 |
|
Stored procedure exceeds 32 k limit...
|
|||
---|---|---|---|
#18+
>А за счет чего был выигрыш? Точно не скажу. Брался запрос, гонялся в Quest Central с изменением уровней оптимизаци, переписыванием самого запроса. Разница между вариантами была в пределах 1.5 сек, что на фоне 10-15 сек.(в зависимости от загруженности сервера) неважно. Как процедуры из QC запускать не знаю. Видимо повлияло то что доступ осуществлялся через ADO и на обработку запроса тратилось больше времени чем на ХП. Причем без разницы была объявлена ХП FENCED или NOT FENCED, процедура выполнялась быстрее. Опять же время на разбор скрипта(не SQL, а ASP) IIS'ом терялось, а в ХП только передавались параметры. Но так же и через компоненты SQL-Direct в Delphi если я возвращал курсор из процедуры то, к примеру, скроллинг таблицы осуществлялся быстрее, чем когда я открывал это как рекордсет. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2003, 08:41 |
|
|
start [/forum/topic.php?fid=43&msg=32275671&tid=1606481]: |
0ms |
get settings: |
7ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
61ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
others: | 312ms |
total: | 457ms |
0 / 0 |