Привет всем.

Подскажите пожалуйста, есть ли ограничение на размер исходного текста хранимой процедуры в FireBird 1.5. Если судить по типу поля, где он хранится, то вроде не должно быть: RDB$PROCEDURE_SOURCE - BLOB SUB_TYPE 1 SEGMENT SIZE 80 CHARACTER SET UNICODE_FSS.

2dimitr

А где это можно вычитать, если не секрет

2 Лентяй

Процедуру разбить конечно можно, интересно же другое: какие у FB существуют ограничения. Если ограниченине на размер BLR, то в него не должны попадать закоментированные каски кода. Если ограничение на размер исходного кода (до 64кб) то моя процедура в это ограничение никак не попадает: до модификации 61119 байт (компилится нормально), после модификации - 63002 байта (не компилиться).

Для проверки я закоментировал добавленный кусок - компилиться не хочет, однако FB ругаестся уже другими словами ():

1) Procedure COMPL$EXTSTATREPTOPRINT00000¤ not found.
2) Name longer than database column size.
3) unsupported DYN verb.
4) Parameter BYDEPCAl+GORIES in procedure COMPL$EXTSTATREPTOPRINT000001 not found.
5) Parameter BYDEPCATEGORI$_ in procedure COMPL$EXTSTATREPTOPRINT000001 not found.

и я думаю, что этот перечень не есть конечный. При этом ХП COMPL$EXTSTATREPTOPRINT00000 ¤ и параметры BYDEPCA l+ GORIES, BYDEPCATEGORI $_ в процедуре не существует.

Пересоздание процедуры помогло - большое спасибо за информацию. Дальше вероятно прийдется делить процедуры или заниматься более детальной оптимизацией кода.

А как на счет ограничения размера BLR в FB2 - оно так и останется 64к, или увеличится (т.е. на что можно ориентироваться в дальнейшем при написании ХП)?

А кто такой F_BLOBSIZE? Вероятно это ф-я, которая возвращает размер blob-поля, но у меня ее нет.

Собственно граничный размер мне нужен, чтоб знать, на что я могу расчитывать при написании ХП.

Гиганские процедуры писать действительно незачем: проблема вылезла при написании довольно простой, но объемной процедуры. Она занимается тем, что разворачивает параметры отчета, лежащие в таблице в виде код параметра - значение в одну строчку т.к. отчет печатается построчно, а таких параметров в разных отчетах может быть много (на данный момент 30*2 - в каждой строке итогового отчета идет строчка за текущий и предыдущий годы и их изменение). Еще она выполняет подсчет итогов по деревовидной иерархии организаций этих-же параметров -> добавляется еще куча переменных для подсчета промежуточных сумм, а еще их надо инициализировать 0, вот и получилось огоромное кол-во кода типа A = 0, B = 0 или A = A + A1 и т.п.

Вот если-бы можно было в ХП работать с массивами, эта огромная процедура сразу уменьшилась бы раза в 3.

Посмотрел данные по размерам BLR и SOURSE для ХП:

исходный размер: SOURSE - 61249, BLR - 33585
Начал добавлять к ней небольшой кусочек - стал грязно ругаться. После пересоздания порцедуры размер SOURSE - 61245, BLR - 34412. До 64к BLR явно не дотягивает.

Параметров всего 77 (11 входящих + 66 возвращаемых). Может это конечно и много, но другого способа получить 63 колонки в отчете я пока не придумал.

Просто когда я что-либо пишу, очень желательно знать какие средства есть у меня в распоряжении. Если ограничение на размер ХП жесткое и в дальнейшем не будет расширено - ну и ладно. Будет над чем подумать в плане оптимизации кода. Главное, чтоб сервер возвращал корректное сообщение об ошибке и все будет ОК.

olol
Seagate Crystal Reports может делать динамические колонки в отчетах...

В этом случае, все колонки идут построчно...

Весь вопрос в том, сколько он стоит