Mannaging SQLConnection / Datasnap über Client-Server-Verbindungen

9

In meiner Datasnap Client-Anwendung verwende ich 1 TSQLConnection für meine Methoden und ProviderConnection. Probleme treten auf, wenn die Verbindung unterbrochen wird. Sowohl TSQLConnection.Connected als auch TSQLConnection.ConnectionState fangen das nicht ein.

Wenn meine TSQL-Verbindung offen ist, aber ich die Internetverbindung verliere oder der Server stoppt. Die Datasnap-Clientanwendung gibt viele Fehler. (Servermethoden oder ClientDatasets)

Ich habe eine Funktion zum Verwalten meiner SQL-Verbindung für meine Servermethoden erstellt. Weitere Probleme treten auf, wenn beispielsweise ein ClientDataset geschlossen wird, das über eine TDSProviderConnection verbunden ist.

F: Wie verwalten Sie Ihre Clientanwendung, um Verbindungsunterbrechungen auf der TSQL-Verbindung sicher abzufangen. Q : Wie verwalten Sie Ausfallzeiten und was tun Sie mit dem Status nicht gespeicherter Clients?

Wiederverbindung nach Ausfall ist nicht das Problem.

Beim Aufruf einer Servermethode: Dies würde eine Ausnahme auslösen.

%Vor%

Also schreibe ich die nächste Methode, um die TSQLCONNECTION von meinem Datamodul mit Dummy-Methode zu erhalten.

%Vor%

Ich habe die Methode auf diese Weise geschrieben, weil ich nur herausfinden kann, ob die Verbindung verloren gegangen ist, durch eine Dummy-Methode, die den gleichen Fehler auslöst ... dann kann ich die Verbindung wiederherstellen oder das Programm schließen.

Bearbeiten: (Ich erwarte eine allgemeine Antwort und Richtlinien, Do's und nicht. Nicht eine Korrektur meines Codes, das ist nur um zu zeigen, was ich gerade mache.)

    
r_j 12.12.2012, 16:30
quelle

1 Antwort

3

Wir haben mit dem gleichen Problem gekämpft - wie man erkennt, wenn die Verbindung getrennt wird, und wie man sich grazil wieder verbindet. Das haben wir getan, was sich für uns als sehr erfolgreich erwiesen hat.

Unsere Benutzer stellen eine Verbindung zum DataSnap-Server her, um Daten abzurufen und Änderungen vorzunehmen. Alle Record-Creates, Updates und Deletes werden sofort über die Ereignishandler OnBeforePost und OnBeforeDelete in TClientDataSet in die Datenbank eingespeist.

Da Sie nicht feststellen können, wann der Client zwangsweise vom DataSnap-Server getrennt wurde, bis Sie versuchen, mit dem Server zu kommunizieren und feststellen, dass die Verbindung unterbrochen wurde, haben wir dem Hauptformular in unserem Verzeichnis TApplicationEvents hinzugefügt App und schrieb einen Event-Handler für das OnException -Ereignis. Wenn wir EIdSocketError sehen, wissen wir, dass die Verbindung tot ist. Daher zeigen wir dem Benutzer eine entsprechende Meldung und rufen dann Abort auf, so dass Post oder Delete nicht im lokalen Dataset vorkommen . Der Benutzer kann sich erneut anmelden und anschließend erneut auf speichern oder löschen klicken, um die vorherige Aktion abzuschließen.

Unser globaler Ausnahme-Handler sieht ungefähr so ​​aus:

%Vor%

Das TDBXError ist ein weiteres, das wir abfangen, da es normalerweise bedeutet, dass ein DB-Fehler aufgetreten ist, wie ein Fremdschlüssel oder eine eindeutige Schlüsselverletzung. Da die Änderung nicht in der Datenbank vorgenommen wurde, haben wir Abort lokal geändert, was uns mit der db synchronisiert.

Da wir die Synchronisation mit der db (über OnBeforePost und OnBeforeDelete ) handhaben, spielt es keine Rolle, dass die Verbindung getrennt wurde und der Benutzer sich erneut verbindet und eine neue DataSnap-Sitzung erhält. Wir können den DataSnap-Server sogar neu starten, ohne dass Benutzer ihre Änderungen verlieren usw. Sie melden sich einfach erneut an und klicken auf Speichern . Nichts ist jemals verloren.

All das beantwortet Ihre erste Frage ... Eines Tages werden wir einen Offline-Modus implementieren, bei dem TClientDataSet auf der Festplatte des Benutzers gespeichert werden kann, und wenn sie sich das nächste Mal einloggen, werden wir eine Synchronisierung durchführen, um alle zu übernehmen lokal gespeicherte Änderungen Aber das haben wir noch nicht getan - also habe ich keine gute Antwort für Ihre zweite Frage.

    
James L. 13.12.2012 23:44
quelle