Insert into

[Walter Landwehr]

An hoika:

Pro Datensatz nicht die 500000
Kein Grid keine weiteren Komponenten.
2 Indizes ; 10 Trigger
prepared := False

An schotti65 :

In IBExpert sehr schnell ca. 1 Sekunde

[Neumann]

Wie sehen denn die Trigger aus, gibt es BeforePost / AfterPost Events?

Normal sollte dieser Vorgang < 50 ms dauern.

[Walter Landwehr]

Kein Before- oder AfterPost

Im Anhang die Trigger.

[jobo]

Wenn es in einem externen Tool schnell geht- wie erwartet-, scheint es ein Codeproblem zu sein.
Was macht die Schleife, die Du mit gepostet hast?
Ist sichergestellt, dass keine Mehrfachinserts mit (verschluckten) Fehlern auftreten?

[jobo]

Nach Übersicht in den Triggern ist es ja doch wohl etwas komplexer.
Es werden diverse Tabellen aktualisiert, dabei werden "sogar" gruppierende Abfragen gemacht, was jetzt nicht mehr unbedingt ne Frage von Millisekunden ist.
Alle Operationen in den Triggern sind der Existenz passender Indizes unterworfen, wenn es um Mengen jenseits von 100000 geht.

Wenn am Ende noch Rechnungsdaten (Gesamtbeträge) aktualisiert werden, kann ich mir auch gut vorstellen, dass es hier einen Sperrkonflikt gibt (der bei einem "Testins Blaue" durch eine autarke DB Query nicht auftritt).

[Walter Landwehr]

Nur mal so zur Info.

Seit Jahren läuft dies eigentlich ohne Probleme. Am Code ist schon seit Jahren nichts geändert worden. Aber seit 2 - 3 Monaten trat dann plötzlich diese Verzögerung ein. Kann es an Firebird liegen?

[p80286]

Zitat von Walter Landwehr:

Nur mal so zur Info.

Seit Jahren läuft dies eigentlich ohne Probleme. Am Code ist schon seit Jahren nichts geändert worden. Aber seit 2 - 3 Monaten trat dann plötzlich diese Verzögerung ein. Kann es an Firebird liegen?

Die Vermutung liegt nahe. Ist irgendein Update gelaufen?

Gruß
K-H

[p80286]

Zitat von jobo:

Ist sichergestellt, dass keine Mehrfachinserts mit (verschluckten) Fehlern auftreten?

Zum einen dies, zum anderen, woher kommt der PK? (kann ich natürlich überlesen haben)

Ich hab so etwas immer so gemacht: (pseudocode)

SQL-Code:

 Insert into table (pk,RechnNr) (newpk,:rechnNr);
Update table set........
where pk=(selekt pk from table where rechnnr=:rechnr)

Etwas umständlich aber wenn Rechnungsnummer eindeutig ist gibt es keine Müllupdates.
ggf sollte natürlich vorher überprüft werden ob die Rechnungsnummer besreits existiert.

Gruß
K-H

[dataspider]

1 Sekunde für 1 Insert in IBExpert ist eigentlich auch langsam, aber na ja...
43 Sekunden füe 1 Insert aus dem Code - da stimmt was nicht

Wenn du IBExpert hast, dann geht duch mal ins Databas Monitoring und schau dir vor allem die Oldest Active Transaction etc. an.
Die Werte sollten nah beieinader liegen, eigentlich um 1 differieren.
Da du IBO benutzt, solte es eigentlich OK sein...

Wenn man wissen will, ob die DB einen weg hat, dann Backup und Restore...

Wie sind die Einstellungen in IBO und was verwendest du? (TIBOTransaction oder TIB_Transaction etc., TIBOQuery oder ...)
Am schnellsten ist IMO TIB_DSQL.
Warum durchläufst du in PatblattQry alle Datensatze unf machst dann ein

Code:

if (PatblattQry.FieldByName('TYP').AsString <> 'Z') then

Warum nicht gleich im SQL von PatblattQry ein

Code:

where typ <> 'Z'

Dann kannst du das if weglassen.

[IBExpert]

Zitat von dataspider:

Wenn du IBExpert hast, dann geht duch mal ins Databas Monitoring und schau dir vor allem die Oldest Active Transaction etc. an.

noch hilfreicher ist es, dafür eine traceapi session zu starten, haben ich in einer der letzten Videos auf www.ibexpert.com/stammtisch geziegt wie das geht