Форум: "Базы";
Текущий архив: 2004.10.03;
Скачать: [xml.tar.bz2];
ВнизНепонятное поведение FB1.5 Найти похожие ветки
← →
bSava © (2004-09-01 10:17) [0]Уважаемые мастера подскажите в каком напрвлении капать???
Ситуация следующая:
есть один запрос в котором помимо всего прочего запрашивается процедура, для каждой записи эта процедура вычисляет ряд значений, запрашивая в свою очередь некоторое количество необходимых таблиц на предмет необходимых данных, и вызываютя необходимые процедуры (если они необходимы), сам запрос примерно следующего вида
(select
)
o.IN,
o.kdc,
o.Name,
sum(ip.iper) as "Iper",
from obekt o
left outer join spisvib(o."ID_Fil", o."ID_Cart", o.id_ob, :D2) sp2 on 0=0
left outer join isn_per(o."ID_Fil", o."ID_Cart", o.id_ob, :D1, sp2.dend) ip on 0=0
where o."DPBuhUch" <= :D2
and sp1.vib <> 1
and o.ID_F = :fil
group by o.IN, o.kdc, o.Name
Так вот проблемма в том, что при вызове этого запроса, как минимум с одной машины в сети, происходит, то, что процедураisn_per
для некоторых записей выдает неверное значение, лечится это дело тем, что на другой машине (как минимум на одной в сети) запускаю этот-же запрос, который выдает правильные данные, после чего на той машине на которой был обнаружен глюк ОДИН раз (иногда раза три) все выводится правильно, потом опять начинаются глюки.
Глюк наблюдается на одной машине, но есть подозрение, что с других просто этот запрос не пускался, или не внимательно анализировался.
Количество получаемых в результате данных около 9000 записей, сервер FB1.5 CS.
В чем дело не могу понять, Buckup/Restore не лечится, помогает но только до первого формирования отчета с той машины.
Пробовал заходить под другим пользователем (с глючной машины), под sysdba вроде глюков не было, но как только вошли под тем пользователем под которым наблюдается глюк, и выполнения данного запроса, смена пользователя на результат не влияла.
Подскажите в чем может быть дело, у меня уже голова кипит.
← →
Digitman © (2004-09-01 13:31) [1]сдается мне, что проблема - в алгоритме самой isn_per()
да и FB1.5 Classic не очень-то внушает доверие.. ну это так, к слову
← →
Роман Снегирев (2004-09-01 14:01) [2]да и FB1.5 Classic не очень-то внушает доверие.. ну это так, к слову
да и делфя то сама тоже не внушает доверия, а чего вообще тебе "внушает доверие"?
← →
Digitman © (2004-09-01 14:21) [3]
> Роман Снегирев (01.09.04 14:01) [2]
> делфя то сама тоже не внушает доверия
это только твои домыслы, не более того
держи себя в курсе событий на sourceforge.net и epsylon.public.interbase - и заметишь, что развитию и устранению багов "классики" разработчиками уделяется заметно меньшее внимание нежели "супера"
← →
Роман Снегирев (2004-09-01 14:26) [4]ну и ставь тогда SuperServer
← →
Digitman © (2004-09-01 14:35) [5]
> Роман Снегирев (01.09.04 14:26) [4]
> ну и ставь тогда SuperServer
это ты мне ?
это ты автору порекомендуй - он бедой мается, а не я
← →
bSava © (2004-09-01 14:39) [6]Я так понимаю совет - перейти на Super?
А если сервак двухпроцессорный? Поменять на однопроцессрный?
> Digitman © (01.09.04 13:31) [1]
> сдается мне, что проблема - в алгоритме самой isn_per()
могу его конечно текс привести, только тепло не будет, потому что там еще процедуры вызываются.
Еслиб проблемма была в ней, то она бы всегда глючила, а то наблюдается плавающий глюк... Что больше всего раздражает...
← →
bSava © (2004-09-01 14:41) [7]
> Digitman ©
> это ты автору порекомендуй - он бедой мается, а не я
Уж маюсь не то слово, можно сказать за.... ну понятно вобщем. :(
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2004.10.03;
Скачать: [xml.tar.bz2];
Память: 0.46 MB
Время: 0.053 c