Firebird 2.1 Absturz

[delling]

Hi,
also ich habe eine UDF geschrieben die mir einige Felder für eine
Ausgabe zusammenrechnet.
Auszug davon siehe unten. Es wird auch nur ein mal suspend'et,
weil ich ja nur die einzelnen Werte brauche.
Wenn ich die proc laufen lasse ist alles ok, beim 2. mal auch noch,
beim 3. oder 4. mal fliegt der Firebird auf dem Server weg und wird von Guardian neu gestartet. Das passiert auch mit dem IBExpert ( für Klemmo )

Lokale Meldung:

-------------------------------------------------------------
Message:
Error reading data from the connection
Type:
EIBInterBaseError
Component:
FormProjekte ...
-------------------------------------------------------------



Eintrag im Serverlog:

-------------------------------------------------------------
GIGA3 (Client) Wed Mar 31 15:33:46 2010
"C:\Programme\Firebird\Firebird_2_1\bin\fbserver.e xe": terminated abnormally (4294967295)

GIGA3 (Client) Wed Mar 31 15:33:47 2010
Guardian starting: "C:\Programme\Firebird\Firebird_2_1\bin\fbserver.e xe"

-------------------------------------------------------------



Firebirdversion: 2.1.3


HILFEEEEEEE !




Auszug aus der Prozedur:

SELECT SUM(BELE_N_NETTO) FROM PROJEKTBELEGE WHERE BELE_A_TYP = 'AU' AND bele_n_projektnr = :inp_projektnr
INTO ut_auftrag;

SELECT SUM(BELE_N_NETTO) FROM PROJEKTBELEGE WHERE BELE_A_TYP = 'RE' AND bele_n_projektnr = :inp_projektnr
INTO ut_rechnung;

SELECT SUM(BELE_N_NETTO) FROM PROJEKTBELEGE WHERE BELE_A_TYP = 'BE' AND bele_n_projektnr = :inp_projektnr
INTO ut_bestellung;

[Hartmuth Prüfer]

Womit wurde die UDF geschrieben?
Wie erfolgte die Deklaration der UDF in Firebird?
Zeige mal den Quelltext oder Auszüge davon.
Ich denke das Problem liegt an der UDF selber. Wenn die nicht "sauber" geschrieben und der Speicher nicht richtig freigegeben wird kommt es zu abstürzen beim Server.

Gruß Hartmuth Prüfer

[delling]

Umnachtung / nicht UDF sondern stored proc

Hi,
also sorry Hartmuth,
es handelt sich nicht um eine UDF sondern um eine einfache stored procedure.
( war etwas verwirrt ...)
Wir arbeiten mit IBExpert ( cooles Tool ... - HK Software).
Dort habe ich die proc geschrieben und ausprobiert.
Aufgerufen wird diese mit Delphi. Der Fehler tritt nie beim ersten Aufruf auf. Auch selten beim 2. Aufruf, aber beim 3. oder 4. fliegt, wie beschrieben, der Server weg... Liegt aber auch nicht am Delphi, weil mit IBExpert passiert das Gleiche.


Procedure im Anhang, weil er mit aufgrund der Doppelpunkte millionen smileys
einfügt und ich keine Ahnung habe wie ich das deaktiviere...

[delling]

nochmal mit Anhang

Den Anhang wollte er nicht, weil der .sql hieß ... habe den jetzt in .txt umbenannt...

[Hartmuth Prüfer]

Die Abfragen in der Prozedure sind ja sehr umfangreich und wenn ich es richtig gesehen habe wird noch eine weiter Prozedur aufgerufen. Was passiert dort?
Den Fehler so zu lokalisieren ohne Daten ist wie in eine Glaskugel schauen
Ich würde mal folgendes versuchen, erst mal einen Exceptionhandling in der Prozedur anlegen.

 WHEN ANY DO
      BEGIN
          -- Hier ggf. die Fehlermeldung zurükgeben
      END

Jetzt mal testen ob sich damit der Fehler abfangen lässt.

Jetzt kommt die eigentliche Arbeit. Schritt für Schritt Teile im Code auskommentieren um dem Fehler auf die Spur zukommen.

Wenn Du Zwischenergebnisse hast einfach posten.

Gruß Hartmuth

PS: Code kannst Du über den Button im Editor mit # einfügen.

[delling]

Hi Hartmuth,
also die Nummer hier ist nicht ganz ohne. Das mit dem Auskommentieren habe ich schon mal gemacht. Wenn ich einiges herausnehme geht dem auch, aber es liegt folgendes Problem vor:


SELECT SUM(BELE_N_NETTO) FROM PROJEKTBELEGE WHERE BELE_A_TYP = 'AU' AND bele_n_projektnr = inp_projektnr
INTO out_auftrag;


greift in eine View, die ist auch recht umfangreich.

Aus dieser View habe ich mehrfach Daten zusammengestellt.
Nachdem ich den Aufruf einige Malei eingetragen hatte bekam ich die Fehlermeldung

too many Contexts of Relation/Procedure/View. Maximum allowed is 255

Ok, also habe ich das in die 2. proz reingesetzt.
Dann kommte ich compilieren.
Bei meinem Versuch wird aber in der proc die Variable inp_art auf 0 gesetzt, also der untere Teil der proz nicht aufgerufen in den der aufruf für die 2. proz steht.
Der Fehler tritt auch auf, wenn ich diesen Part auskommentiere.

Ich hänge mal die VIEW und die Prozeduren an....

Ich denke ja, dass es mit der view zusammenhängt,

[Hartmuth Prüfer]

Ich habe mal über Deine View geschaut. Du verwendest in der Spaltenabfrage mehrfach SELECT. Bis Du sicher, dass immer genau nur ein Datensatz auch zurückgegebn wird?
Ich versuche so etwas immer zu umgehen. Ich würde die Abfragen umbauen.
Benutzt Du die View noch an anderen Stellen? Sonst würde ich auch über eine SP nachdenken.


Gruß Hartmuth

[delling]

select in view

Hi Hartmuth,

also das select geht immer auf eindeutige Indexe. Da kann immer nur ein Satz zurückkommen. ( Rechnungsnummer oder Zugangsnummer ...)
Die View verwende ich an einer anderen Stelle in der Projektverwaltung zur Anzeige aller Dokumente. Da gab es in den letzten Monaten nie ein Problem.
Ich verstehe aber nicht, wieso mir der Firebird diese Mitteilung mit der
Abfrage zu lang hinwirft, wenn ich in der proz mehrfach aus der view summiere.

Gundsätzlich wollte ich natürlich Alles an einer Stelle lassen.
Über die View werden im Programm alle Dokumente zum Projekt angezeigt.
Wenn ich jetzt für das Drucken was anderes erfinden muss ist halt
Redundanz da und irgendwann Stress vorprogrammiert, weil die Anzeige vom Druck abweicht ...

Ist Dir die Fehlermeldung

too many Contexts of Relation/Procedure/View. Maximum allowed is 255

ein Begriff ?

Habe mal gegoogelt, aber nix wirklich brauchbares gefunden.
Was darf da nur 255 lang sein ?
In der Def. der View habe ich viel längere Sachen drin.






Gruß jens

[Hartmuth Prüfer]

too many Contexts of Relation/Procedure/View. Maximum allowed is 255

Die Fehlermeldung ist mir noch nicht über den Weg gelaufen.
Interpretieren würde ich die Meldung so, dass die Selects aus Tabellen/Views beim Auflösen durch den Optimizer und dem Ausführen zu groß wird. Er kommt an eine Grenze. Was da intern passiert kann ich auch nicht erklären. Die Komplexität der Abfrage überfordert ihn wohl.
Was mich aber wundert, dass er die Abfrage dann überhaupt einmal ausführt.
Ich würde versuchen ob sich die Selects nicht optimieren lassen.

Gruß Hartmuth

[delling]

Hi Hartmuth,

vielen Dank für Deine Bemühungen.
Klar kann ich die View optimieren und die proz in verschiedene Parts teilen.
Also das Problem umschiffen.
Die ganze Aktion hinterläßt aber ein verdammt ungutes Gefühl in der
Magengegend. Man programmiert was, testet und irgendwann beim
Kunden fliegt der Server weg.
Keine Ahnung was jetzt als Testroutinen kreiert werden soll um
halbwegs sicher zu sein. Man kann sich ja dann auf nichts mehr verlassen.

Vor Allem wenn man keine Ahnung von den Ursachen hat und nicht weiß
WAS man vermeiden muss.

Gruß jens

[Klemmo]

du musst vorsichtig sein mit deinen Verschachtelungen vor dem From in deinen SQLs, diese werden je nach Art wie Multiple Joins pro Record aufgelöst und damit landest du schnell an den Grenzen von 255.

Ich persönlich muss sagen, das deine SQLs auch extrem schwierig lesbar sind, daher wäre modularisierung mehr als angebracht. Versuch doch einfach mal so was wie das hier in eine eigene prozedur zu packen und dann per execute procedure .... returning values .... einfach einzubinden. Das vereinfacht sowohl debuggung als auch performanceanalyse erheblich (ist übrigens schon durch den formatter in IBE gelaufen)

  select sum(iif(exists(select *
                        from CHARGEN
                        where CHAR_N_STAPELNR = ZUGA_N_NR and
                              coalesce(CHAR_N_PROJEKT_NR, 0) <> 0 and
                              coalesce(CHAR_N_PROJEKT_NR, 0) <> ZUGA_N_PROJEKT_NR),
         (select sum(round(100 * (round(100 * (round(100 * CHAR_N_EKPREIS_ORG * CHAR_N_MENGE) / 100) * (1 - coalesce(CHAR_N_RABATT, 0) / 100)) / 100) / iif(coalesce(CHAR_N_MENGENFAKTOR, 0) < 1, 1, CHAR_N_MENGENFAKTOR)) / 100)
          from CHARGEN
          where CHAR_N_STAPELNR = ZUGA_N_NR and
                ((coalesce(CHAR_N_PROJEKT_NR, 0) = ZUGA_N_PROJEKT_NR) or (coalesce(CHAR_N_PROJEKT_NR, 0) = 0))) - coalesce((select sum(PRTW_N_BETRAG)
                                                                                                                            from PROJEKT_TEILWERTE
                                                                                                                            where PRTW_N_BELEGNR = ZUGA_N_NR and
                                                                                                                                  PRTW_N_NR <> ZUGA_N_PROJEKT_NR), 0), ZUGA_N_NETTO - coalesce((select sum(PRTW_N_BETRAG)
                                                                                                                                                                                                from PROJEKT_TEILWERTE
                                                                                                                                                                                                where PRTW_N_BELEGNR = ZUGA_N_NR and
                                                                                                                                                                                                      PRTW_N_NR <> ZUGA_N_PROJEKT_NR), 0)))
  from ZUGAENGE
  where ZUGA_N_PROJEKT_NR = :INP_PROJEKTNR
  into :OUT_ZUGANG;

evtl nutzt du in IBExpert auf einfach mal die Codeformatierung
http://www.ibexpert.net/ibe/index.ph...mattingOptions

geht per toolbutton im SP Editor und das macht das dann schon wesentlich übersichtlicher



Gruß
Holger
www.ibexpert.com