Daher habe ich mir überlegt, einen Windows-Dienst zu schreiben. Dieser läuft auf dem Windows-Server 24/7. Programme/Plugins können bauen eine
TCP-Verbindung zum Dienst auf, senden ihm ein command (zB getTasks), der Dienst verbindet sich zur Datenbank, liest die Daten aus und sendet sie per
tcp (hier meine ich
Indy-
TCP-Server/Client) an den Clientprozess zurück. Wenn keine Internetverbindung besteht, kann man das echt gut abfangen und es wäre immer nur eine Datenbankverbindung (nämlich Dienst <-> Datenbank) geöffnet. Alle Datenbankoperationen (hinzufügen, ändern, löschen) würden dann vom Dienst übernommen werden. Dies ist auch einfacher zu Warten.
Interessant... Ich arbeite zur Zeit an einer ähnlichen Lösung aufgrund von ähnlichen Problemen.
Mein Ansatz ist zwar etwas anders aber läuft aufs gleiche hinaus.
Clientseitig nur mir meiner Schicht reden ohne eine Datenbank Komponente. Somit kann ich in 2 Sekunden meine Software von Datenbank A auf Datenbank B umstellen uvm.
Indy ist entgegen von overbyte meine Wahl, da die Overbyte Sourcen nicht Android/iOS kompatible sind. (Nach meinen Wissen, obwohl ich ein Overbyte-Fan bin).
Wichtig für mich ist auch ein "Shoot & Forget" ich mache 10000 Posts und meine App arbeitet sofort weiter als währen die Daten schon in der Datenbank angekommen... Die Zwischenschicht kann dann in einem netten WorkerThread die Daten "in Ruhe" weg schreiben und nur ggf. im Fehlerfall mir einen Callback schicken. (Vereinfacht)
Daher je einen Teil der Zwischenschicht in jedem Client und den anderen Teil zentral/dezentral. Hier können auch mehrere Server dann Synchronisiert werden.
Mavarik
PS.: Momentan "bastel" ich noch an einem Konzept für eine SELECT bla JOIN bla Umsetzung.