![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Весь в непонятках. Хранимая процедура(+) [IB6.x]
AlexSerp © (2004-05-19 12:09:00)имеет 71 возвращаемое поле.
Работает на отчет (по авансовым отчетам).
Попросили добавить пару полей.
Добавил. Один сотрудник из отчета пропал.
Убрал те два поля, все появилось.
Никакой логики никак не могу увидеть.
Это глюк или ограичение ИБ6?
Что-то я нигде таких ограничений не видел.
Или плохо смотрел?
AlexSerp (2004-05-19 13:48:00) [21]declare variable SALDO_AV DOUBLE PRECISION;
declare variable SALDO_W1 DOUBLE PRECISION;
declare variable SALDO_KO DOUBLE PRECISION;
declare variable SALDO_W DOUBLE PRECISION;
declare variable SALDO_N DOUBLE PRECISION;
declare variable SALDO_76 DOUBLE PRECISION;
/*declare variable SM_DB1 DOUBLE PRECISION;*/
/*declare variable SM_KR1 DOUBLE PRECISION;*/
/*declare variable SM_SH DOUBLE PRECISION;*/
declare variable NN INTEGER;
declare variable DN INTEGER;
declare variable STR VARCHAR(10);
declare variable DATA_W DATE;
/*declare variable SH1 VARCHAR (15);*/
BEGIN
DAN=DATA_N; DAK=DATA_K;
NOM_AVOT=''; NN=0; NSTR=0;SM_KR1=0;SM_DB1=0;
SM_DB_KR=0;
for
Select A.A1,min(B.NAME) from BUX_SALDO A
left join SOTRUD B on (A.A1=B.N)
where A.DB like '710%'
and A.GOD=:GOD
and A.mes=:mes
group by A.A1
union
Select A.KLIENT_N,min(B.NAME) from BUX_OBOROT A
left join SOTRUD B on (A.KLIENT_N=B.N)
where A.modul in (5,51)
/*and A.GOD=:GOD*/
and a.data between :data_n and :data_k
group by A.KLIENT_N
into :N_SOTR,:FIO
do begin
SM_DBN=Null; SM_KRN=Null; SM=Null;
if (N_SOTR is Null) then N_SOTR=0;
if (FIO is Null) then FIO='нет';
NOM_AVOT='';
for
Select N_N from DOK_OSN_AV where ROD1=:N_SOTR
and DATA>=:DATA_N and DATA<=:DATA_K
into :NN do begin
if (NN is Null) then NN=0;
NOM_AVOT=NOM_AVOT||','||CAST(NN as varchar(10));
end
/*SALDO_N*/
Select sum(SM) from BUX_SALDO
where A1=:N_SOTR and DB like '7101%'
and MES=:MES and GOD=:GOD
into :SM;
if (SM is Null) then SM=0;
if (SM=0) then begin
SM_DBN=Null; SM_KRN=Null; SM=Null;
end
if (SM<0) then begin
SM_KRN=-SM; SM_DBN=Null;
end
if (SM>0) then begin
SM_DBN=SM; SM_KRN=Null;
end
/*SM DEBET*/
SM_SH=0;
SM_7102=0;
SM_7102D=0;
SM_5002D=0;
SM_910421D=0;
SM_51=0; SM_50K=0;
SM_5101=0;
SM_5102=0;
SM_5103=0;
SM_5104=0;
SM_5105=0;
SM_5106=0;
SM_5107=0;
SM_5108=0;
SM_5001K=0;
SM_5004=0;
SM_7902=0;
/*SM KREDIT*/
SM_SH=0;SM_50D=0;SM_4402=0;SM_260022124=0;SM_230000012=0;
SM_260011310=0;SM_260033365=0;SM_6021=0;SM_6021KOM=0;
SM_19042=0;SM_8402=0;SM_9104=0;SM_7302=0;
SM_5001D=0;
SM_0804=0;
SM_1001111=0;
SM_1003000=0;
SM_1003100=0;
SM_1003200=0;
SM_1005000=0;
SM_1006=0;
SM_1009000=0;
SM_230078027=0;
AlexSerp (2004-05-19 13:47:00) [22]ОК
CREATE PROCEDURE GURNAL_SCHET_71S (SM_5002D DOUBLE PRECISION,
DATA_N DATE,
DATA_K DATE,
SH VARCHAR (15),
MES INTEGER,
GOD INTEGER)
RETURNS (
NSTR INTEGER,
FIO VARCHAR (30),
SM_DBN DOUBLE PRECISION,
SM_KRN DOUBLE PRECISION,
SM DOUBLE PRECISION,
SM_7102 DOUBLE PRECISION,
SM_7102D DOUBLE PRECISION,
SM_910421D DOUBLE PRECISION,
SM_51 DOUBLE PRECISION,
SM_5101 DOUBLE PRECISION,
SM_5102 DOUBLE PRECISION,
SM_5103 DOUBLE PRECISION,
SM_5104 DOUBLE PRECISION,
SM_5105 DOUBLE PRECISION,
SM_5106 DOUBLE PRECISION,
SM_5107 DOUBLE PRECISION,
SM_5108 DOUBLE PRECISION,
SM_5001K DOUBLE PRECISION,
SM_5004 DOUBLE PRECISION,
SM_7902 DOUBLE PRECISION,
SM_7902K DOUBLE PRECISION,
DATA DATE,
SM_50K DOUBLE PRECISION,
SM_50D DOUBLE PRECISION,
SM_5001D DOUBLE PRECISION,
SM_4402 DOUBLE PRECISION,
SM_260022124 DOUBLE PRECISION,
SM_230000012 DOUBLE PRECISION,
SM_260011310 DOUBLE PRECISION,
SM_260033365 DOUBLE PRECISION,
SM_6021 DOUBLE PRECISION,
SM_6021KOM DOUBLE PRECISION,
SM_19042 DOUBLE PRECISION,
SM_8402 DOUBLE PRECISION,
SM_9104 DOUBLE PRECISION,
SM_7302 DOUBLE PRECISION,
SM_7307 DOUBLE PRECISION,
SM_0804 DOUBLE PRECISION,
SM_1001111 DOUBLE PRECISION,
SM_1003000 DOUBLE PRECISION,
SM_1003100 DOUBLE PRECISION,
SM_1003200 DOUBLE PRECISION,
SM_1005000 DOUBLE PRECISION,
SM_1006 DOUBLE PRECISION,
SM_1009000 DOUBLE PRECISION,
SM_230078027 DOUBLE PRECISION,
SM_260022128 DOUBLE PRECISION,
SM_260022130 DOUBLE PRECISION,
SM_4401 DOUBLE PRECISION,
SM_4403 DOUBLE PRECISION,
SM_910494 DOUBLE PRECISION,
SM_9703 DOUBLE PRECISION,
SM_8401 DOUBLE PRECISION,
SM_1002200 DOUBLE PRECISION,
SM_1008 DOUBLE PRECISION,
SM_910451 DOUBLE PRECISION,
SM_230071027 DOUBLE PRECISION,
SM_ITOGO DOUBLE PRECISION,
NOM_AVOT VARCHAR (150),
SM_DB_KR DOUBLE PRECISION,
SM_DBK DOUBLE PRECISION,
SM_KRK DOUBLE PRECISION,
DAN DATE,
DAK DATE,
N_SOTR INTEGER,
SM_SH DOUBLE PRECISION,
SH1 VARCHAR (15),
SH2 VARCHAR (15),
SM_DB1 DOUBLE PRECISION,
SM_KR1 DOUBLE PRECISION,
N_BUX INTEGER,
NS INTEGER)
AS
Соловьев (2004-05-19 13:44:00) [23]
> [11] AlexSerp (19.05.04 13:37)
можно же и частями опубликовать...
AlexSerp (2004-05-19 13:37:00) [24]Andriano, я уже все объединения проверил.
Текст процедуры выложить не могу - ограничение на длинну сообщения в форуме.
По поводу объединений - без двух доп.полей работает.
Значит дело все-таки не в объединениях.
Andriano (2004-05-19 13:32:00) [25]Ну а что по поводу "неверных внешних объединений" - проверил?
Давно бы запрос показал.
И вообще, ну не может быть в отчете по авансовым платежам 71 поле.
Соловьев (2004-05-19 13:31:00) [26]
> [8] AlexSerp (19.05.04 13:28)
:)
это я шутил
ты вопрос такой задал - что только телепаты догажаются...
приведи код ХП, и вообще-то уже пора давно перейти на FireBird 1.5
AlexSerp (2004-05-19 13:28:00) [27]Соловьев, а есть решение против известного глюка?
Извини, я пока не нашел в инете.
AlexSerp (2004-05-19 13:24:00) [28]Digitman> это же ужас какой-то ! куда ж ты их столько настрогал ?)
Я всего лишь админ. Проги/отчеты и все такое написано не мной.
Я на развитии и устранении багов.
Вообще-то и побольше процедуры встречаются.
Так что вопрос не в этом.
Ладно бы вообще результата не было.
А то ведь строка из отчета.
Причем, если каждый запрос в процедуре запускать по этому сотруднику, то вся инфа на месте. А возврат из процедуры без него.
Val (2004-05-19 13:13:00) [29]сотрудники могут пропадать из-за неверных внешних объединений :)
Digitman (2004-05-19 12:58:00) [30]
> имеет 71 возвращаемое поле
это же ужас какой-то ! куда ж ты их столько настрогал ?)
что-то, думаю, изначально неверно в логике таких "монстрообразных" запросов ...
Курдль (2004-05-19 12:56:00) [31]
> Vlad © (19.05.04 12:21) [3]
> В IB количество полей ограничивается размером записи - 64К,
> сюда не входят блобы
Представьте себе 64К - это ж скока текста!
Vlad (2004-05-19 12:21:00) [32]В IB количество полей ограничивается размером записи - 64К, сюда не входят блобы
Курдль (2004-05-19 12:17:00) [33]
> Один сотрудник из отчета пропал.
Ну хоть в мире живых остался? :(
Соловьев (2004-05-19 12:12:00) [34]ошибка в 301 строке ХП - известный глюк ИБ