Mehrere DB-Verbindungen aus Dienst überfordern Firebird ?!

[mkinzler]

Die BDE kann m.W. aber nur SoftCommits ( gleiches Problem wie bei Zeos)

[DataCool]

@neo4All:

Es sind definitiv keine Trigger oder SP's involviert !!!

@hoika:
Die BDE Einstellungen stehen auf "Shared No autocimmit".
StartTransaction, Commit, Rollback verwende ich nur expilzit innerhalb der User-App bei längeren Operationen.

Um etwas Licht ins dunkle zu bringen:

Ich habe eine Datenbank, wo die "wirklichen" Daten der Applikation enthalten sind,
zusätzlich gibt es in dieser DB noch eine Tabelle "SQL_TRANSFER" in der ich
jedes Änderungsstatement(Insert, Update, Delete) speichere(zur Syncronisierung mit einer DB im RZ).
Normalegröße: 2MB - 40 MB.

Dann gibt es eine 2te Datenbank die Daten aus einem Kassensystem via Exportfile importiert,
da steht dann jeder "Sch.." Bon, Artikel und Tastendruck eines Kellners drin.
Der Import läuft innerhalb eines Dienstes(innerhalb eines Timers, wenn Exportdatei vorhanden).
Der Dienst hat eine Verbindung zu DB1 und zu DB2,
um in DB2 die Kassendaten zu schreiben und in DB1 die "SQLs zu locken".

Ein Thread innerhalb des Dienstes syncronisiert dann via Internet die SQLS mit einem Server im RZ.


Konflikte könnte es geben:

- Wenn die Exportdatei importiert wird und eine User die GUI App nutzt, schreiben beide(Dienst und App)
in "SQL_Transfer"(App nur schreiben und Dienst schreiben und Lesen)

- Wenn der Dienst fertig mit import ist schreibt er 1 SQL zur Änderung in in DB1(Update auf den Umsatz eines Tages),
theoretisch könnte ein User mit der Gui auch gerade diesen Tag bearbeiten.

Ich weiß eine sehr seltsame Konstruktion, aber das System ist seit Jahren gewachsen.
Früher hatte ich die SQL-Syncronisation auch einfach via File-Transfer an den Server gemacht(komplette DB) und
der Server hat das ganze dann mit BatchMove gemerged.
Das geht jetzt aber nicht mehr, weil die Kassendaten auch in RZ sollen und da reden wir von Daten zwischen 200 MB bis 1 GB.
Deshalb die Idee mit dem SQL locken und transferieren, aber seitdem gibt es halt die bEschriebenen Probleme aber auch nur sporadisch und nicht in allen Läden.

Hoffe Ablauf ist klar geworden,

Greetz Data

[DataCool]

^^^???? ^^^^ Jetzt kein Kommentar mehr ?

Noch eine Zwischenfrage:

Würde es helfen, wenn die DB-Connection aus dem Dienst direkt ohne BDE gemacht werden ?

Greetz DAta

[hoika]

Hallo,

solange du nicht weisst, wo der Fehler ist,
kann man das nicht beantworten.
Schon mal an Loggen in eine externe Textdatei gedacht ?


Heiko

[neo4a]

@Heiko,

es wird ihm nicht viel nutzen, die Aktivitäten zu loggen. Das ist sehr aufwändig und bei seinem Szenario kaum nachzuvollziehen. Ich halte es da lieber mit Jason Wharton (IBObjects): Watch your Transactions! Firebird weigert sich zum Beispiel auch, einen Satz einzufügen bei einer Primary Key violation. Tritt niemals auf, wenn sie generell per Generator in Triggern gesetzt werden, aber das setzt ja der OP nicht ein.

Wenn ich nun den Ablauf richtig deute, gibt es praktisch keine Edits oder Deletes, nur Inserts. Wie werden dann die PK ermittelt? Beim Schreiben in welche Tabelle bleiben denn die Clients hängen? Hier würde ich meine Applikation etwas "gesprächiger" machen.

Der OP versorgt uns leider nur bruchstückweise mit Infos und vertraut auf die gut geputzten Glaskugeln der Mitleser.

--
Andreas

[DataCool]

@Heiko:
Neo hat Recht per Logging kommt man dem Fehler nicht zu Rande.
Die Query bekommt auch keinen Fehler, ich finde zumindest in meinen LOgfiles keinen.
Der neue oder geänderte Datensatz wird einfach nicht gespeichert.

@Neo:
Da es sich bei der Gui-DB(DB1) um eine DB handelt die Zentral gemerched wird,
werden die PK anhand von Nummernkreisen berechnet abhängig von der ID des Standorts.
Ermittelt mit:
"Select max(xyz) from Tblxyz where (xyz > blamin) and (xyz < blaMax)"
Das Ergebnis dann + 1 ergibt die neue ID.

Und ja Neo beim Import den der Dienst durchführt gibt es zu 95% nur Inserts,
allerdings auch ein paar Updates da die Daten des Exports nicht unbedingt in einem Stück kommen.

Beim Speichern des SQL-Befehle gibt es nur Inserts.

Beim Thread der aus dem Dienst zum RZ des SQLs syncronisiert gibt es nur Updates(zu bearbeitene Datensätze werden via Flag markiert),
dann sequentiell übertragen und danach alle markierten Datensätze gelöscht.

Die Fehler treten laut Kundenaussagen aber nachher bei Stammdaten des Programms auf, die bei dem ganzen Kram nicht angepackt werden,
Oder es wird gar nichts mehr gespeichert.

Abhilfe bringt dann wie gesagt Neustart des Rechners, oder meine App beenden, meinen Dienst beenden und Firebird Dienst neu starten.

Habe das ganze jetzt soweit geändert das jedes TDatabase in meinem Dienst in einer eigenen Session läuft,
denke bin heute Abend soweit ein paar Tests zu fahren.

Wenn Ihr noch mehr Infos braucht, sagt wie ich Licht ins Dunkle bringen kann.

Greetz Data

[neo4a]

Auch wenn es vielleicht nicht Dein primäres Problem ist: Die Art, wie Du den PK ermitteln lässt, ist in einer Mehrbenutzerumgebung wirklich völlig ungeeignet. Es sind unter allen Umständen Generatoren zu benutzen, da nur sie außerhalb einer Transaktion verwaltet werden. (Bitte nicht darüber diskutieren, sonder Helen Borries Firebird-Buch lesen.) Auch mit Generatoren kann man PK unter Berücksichtung von Nummernkreisen verwalten, damit Multipoint-Replikationen funktionieren. Ein alternativer Ansatz sind GUID als PK, aber das führt jetzt wirklich am Thread-Thema vorbei.

Deine Schilderung der Probleme lässt mich mutmaßen, dass bei Deinen Clients schlicht die Verbindung zur DB abbricht. Vielleicht stürzt sogar der FB-Server ab und es merkt keiner, weil der Guardian gleich wieder startet. Das steht in den Server-Logs oder im Ereignisprotokoll (ich hoffe, Du fährtst nicht noch Win9x/Me-Rechner). Oder es gibt ein Transaktions-Timeout und die BDE versagt.

Was die BDE anbelangt, so kann ich nur schwer helfen, denn ich setze sie nicht ein.

Weitere lustige Fehlerquellen sind unterschiedliche FB-DLL (gds32.dll) auf Client(s) und Server oder gemischte Connections (local,TCPIP). Letzteres führt auch gerne zu DB-Defekten.

--
Andreas

[DataCool]

@neo:
Thema ID Vergabe hast Du absolut recht, lokal wird aber definitiv immer nur mit einem PC gearbeitet.

Die Idee mit dem kurzzeitigen Verbindungsabbruch werde ich mal nachgehen, das könnte eine logische Erklärung sein,
denn der Firebird-Server geht beim Import der Kassendaten so in die Knie(CPU-Last maximum),
das vielleicht die Gui-App Ihre Connection verliert.

^^ Werde ich prüfen ^^

Thx & Greetz DAta

[neo4a]

Auch wenn Du nur mit einem PC arbeitest, hast Du mit der Client-Applikation und dem Dienst praktisch eine Mehrbenutzerumgebung. Da greifen alle Gefahren bei der PrimaryKey (PK)- Ermittlung.

Wenn also Dein Dienst seine Transaktion nach dem Insert noch nicht beendet hat, wird die Applikation in dieser Zeit per SQL-Max() einen PK- Wert bekommen, der aber bereits vom Dienst verbraucht wurde. Das ist ein typisches Deathlock- Szenario, das man häufig nur durch Dienst-Neustart (und Datenverlust!) lösen kann.

Und weil ich so schön am Erklären bin: Genau die Transaktionen sind auch der Grund, weshalb gerade beim Import (also Mengen- Inserts) ein FB- Server in die Knie gezwungen werden kann. Hier macht ein erfahrener Programmierer nach einer Anzahl von Inserts (z.B 100 oder 1000) ein "Commit work;" und passt auf, das keine Transaktion länger dauert als nötig (Stichwort OAT - oldest active transaction).

Viel Erfolg.

--
Andreas

[DataCool]

@neo:
Gebe mich geschlagen, war nicht das beste Konzept damals ist auch schon über 8 Jahre her die erste Version.
Das Problem scheint sich auch erst jetzt wirklich bemerkbar zu machen, seitdem ich die SQL-Statements zur
Übertragung sichere.
Denke auch schon länger darüber nach die DB zu wechseln bzw. auf Firebird 2 umzusteigen.
Allerdings muss ich die Umstellung automatisiert in meine Online-Update Routine einbauen,
den ca. 120 Läden per Hand zu aktualisieren(nebenberuflich) ist doch etwas schwierig.
Für die Automatisierung habe ich leider noch keine ausgearbeitetes Konzept.

Deshalb war ich auf der Suche nach einer "Quick & Dirty" Lösung um das "Problem"
bis zum großen Update vom Hals zu haben.

Das einzige was mir im Moment spontan einfällt ist,
den Table zum SQL-Logging aus DB1 zu entfernen und in eine dritte neue DB(mit SP und Generator zur ID Erzeugung) zu portieren.
So würde die Client GUI nur in DB1 Lesen und schreiben.
Der Dienst würde die Import Daten in DB2 schreiben.
Und in DB3(nur ein Table zum SQL logging) würden beide Lesen und schreiben, allerdings wäre die ID Generierung durch den Generator dann geschützt.

Oder hast Du eine noch bessere Idee ?!

Greetz Data