Firebird Fehlerhaftes Returning

[Lemmy]

Zitat von Pro_RJ:

Das Problem ist nicht, das die Funktion IBSQL.FieldByName('Zaehler').asInteger nicht geht. das Problem liegt darin, das der Server den Wert nicht an den Client übermittelt,

Und da bist Du dir absolut sicher (SQL-Monitor usw.)? Ich habe die 2.1.1 im Einsatz und auch eine Stelle mit Returning - damit hatte ich bei meinen Kunden noch kein Problem (das sind einige tausend Installationen die diese Funktion nutzen).

GRüße

[Pro_RJ]

Da bin ich mir absolut relativ sicher da der Datensatz Serverseitig den richtigen Zähler hat.

ich kann das ganze sehr einfach und sicher prüfen:
Es handelt sich hier um eine schnittstelle. diese Daten werden im 1. Schritt in eine Zwischentabelle gespeichert. "TBL_A". Anschliesend wird diese Eingefügte Datenmenge in einer Schleife durchgearbeitet und diese erzeugt zusätzliche Daten "TBL_B"

der Ablauf ist (schematisch Dargestellt) folgender:

Delphi-Quellcode:

Transaction Starten;
While not TBL_A.Eof do
Begin
  INC(I);
  IBSQL.CLose;
  IBSQL.SQL.Text := 'Insert into TBL_B(Nr) values (' + IntToStr(TBL_a.FieldByName('Zaehler').asINteger) + ') returing Zaehler';
  IBSQL.Execsql;

  Zaehler := IBSQL1.FIeldByName('Zaehler').asNteger;
  IBSQL.CLose;
  IBSQL.SQL.Text := 'Update TBL_A set FremdID = ' + IntToStr(Zaehler) + ' where Zaehler = ' + IntToStr(TBL_a.FieldByName('Zaehler').asINteger);
  IBSQL.Execsql
  TBL_A.Next;
end;
Transaction Commit;

Das heist das es pro TBL_A Datensatz auch einen TBL_B Datensatz geben muss (1=1 Verbindung).
In TBL_A speichere ich mir den neuen Zaehler aus TBL_B und in TBL_B steht der Zaehler aus TBL_A.

Jetzt ist ab und zu mal das Problem, das in TBL_A UND TBL_B ein Datensatz vorhanden ist. In TBL_B steht ein Zaehler aus TBL_A aber in TBL_A ist das Feld Fremd_ID 0 und das Kann einfach nicht sein.

[tsteinmaurer]

Ich selbst hatte damit auch noch nie Probleme, verwende allerdings IBObjects bzw. IBDAC.

@Lemmy: Einige Tausende Installationen? Bist du Mitglieder der Foundation? SCNR.

[tsteinmaurer]

@Pro_RJ: Wenn er serverseitig passt, dann ist das a) ein Indiz dafür, dass die Verwendung im Code nicht passt oder halt IBX das RETURNING nicht unterstützt. Bzgl. Verwendung FieldByName/ParamByName wird es vermutlich auch in IBX davon abhängen, ob man eine Ergebnismenge offen hat oder nicht. Stichwort Open vs. ExecSQL.

[Pro_RJ]

Zitat von tsteinmaurer:

@Pro_RJ: Wenn er serverseitig passt, dann ist das a) ein Indiz dafür, dass die Verwendung im Code nicht passt oder halt IBX das RETURNING nicht unterstützt. Bzgl. Verwendung FieldByName/ParamByName wird es vermutlich auch in IBX davon abhängen, ob man eine Ergebnismenge offen hat oder nicht. Stichwort Open vs. ExecSQL.

Aber warum funktioniert dann diese Scheife einige 100K mal und nur in einem Passt der wert nicht. DIe Daten sind immer die gleichen, die Schleife ist immer gleich, das Einfügen ist immer gleich es ist alles Identisch und bei allen Statements ist der wert in FIeldByName vorhanden nur ab und zu mal nicht


PS: Ein IBSQL.Open gibt es so nicht, das ist lediglich eine "nur lesen" eigentschaft, mit der geprüft werden kann ob die Datenmenge Aktiv ist oder nicht. Aber man dann damit keine Datenmenge öffen oder ein Statement absetzen

[Lemmy]

Zitat von tsteinmaurer:

@Lemmy: Einige Tausende Installationen? Bist du Mitglieder der Foundation? SCNR.

Auf verflixt... erwischt... aber ich habe ne gute Entschuldigung: Ist mein Arbeitgeber - d.h. ich bin "auch" nur ein armer kleiner Angestellter. Allerdings werde ich mal schauen was geht.

[tsteinmaurer]

@Pro_RJ: Hab mir jetzt nochmal dein Delphi-Pseudo-Code Beispiel angesehen, und werde daraus nicht wirklich schlau.

* Kannst mal die DDL inkl. Trigger der beteiligten Tabellen posten?
* Generell würde ich dir auch raten, dass du in der Schleife nicht immer den SQL.Text neu setzt, sondern außerhalb der Schleife das SQL zusammenbaust, ein Prepare machst und innerhalb dann nur die Parameterwerte austauscht. Sollte bzgl. Performanz einiges bringen
* Spricht etwas dagegeben, das Ganze in einer Stored Procedure zu machen? Da würde dann so richtig die Post abgehen.

[Pro_RJ]

Das Posten der Tabelle ist schwierig,
da etwar 20-25 Verschiedene (und Stellenweise sehr Komplexe tabellen vorhanden sind)

Der Pseudo-Code ist auch nur ein Beispiel. Es Handelt sich hierbei um den Abruf von externen Registrierkassen (den Namen lass ich einfach mal weg ) Über diese Kassen werden Bestellung,Retouren,Inventuren,Arbeitszeiten,Produ ktionen und Verkäufe getätigt und diese Daten werden von uns aus den Kassen abgeholt, zwischengespeichert und in unsere Warenwirtschaft eingepflegt. Deshalb kann ich leider nur PseudoCode anbieten.

Eine SP wäre grundsätzlich eine gute Idee ist nur leider ein riesiger aufwand.
wobei die Geschwindigkeit auch nicht das Problem ist.
Es sind 80 Kassen und jede Kasse liefer ca 20.000 - 30.000 Daten. Diese Werden per ISDN in ca 45-60 abgeholt und in ca 2-3 Stunden Verarbeitet anschießen werden die Kassen noch Akutalisiert und wieder gesendet.

[tsteinmaurer]

Mit diesen Informationen kann ich leider nicht mehr weiterhelfen. Bei Interesse können wir das auf kommerzieller, privater Basis mit Verschwiegenheitsklausel etc. abhandeln.

[Pro_RJ]

Zitat von tsteinmaurer:

Mit diesen Informationen kann ich leider nicht mehr weiterhelfen. Bei Interesse können wir das auf kommerzieller, privater Basis mit Verschwiegenheitsklausel etc. abhandeln.

Ich weis, das es leider seher schwierig ist, mit den wenigen Informationen weitere Tipps zu geben. ich bau mir erstmal ein Work-Around um das Problem anders zu lösen.


Danke schonmal an die Vielen Tips.