Mein eigentliches Problem ist aber, dass ich zumindest bei diesem Projekt sicherstellen muss, dass während des
DB-Updates alle Benutzer von der Datenbank getrennt sind.
....und während des Updatevorganges kein ReConnect eines Clients stattfinden darf.
Dieses Problem löse ich wie folgt: Auf dem Server liegt eine Tabelle mit Login-Logout-Informationen jedes Clients, physikalischer Dateiname "Logbuch". Darin wird protokolliert, wann User im Netzwerk ein Programm starten, und wann (und ob) sie es wieder ordnungsgemäß beenden. Bei einem Update ohne strukturelle Änderungen an der
DB (ein quasi On-the-Fly-Update) bleibt die Struktur dieser Tabelle gleich. Wenn aber - so wie vermutlich auch bei dir - strukturelle Änderungen an den Datenbanken vorgenommen werden (müssen) gehe ich wie folgt vor:
- der
DB-Server-Dienst wird beendet
-
TCP/
IP wird im
DB-Server deaktiviert
- der
DB-Server wird mit lokalem Zugriff (named Pipe) gestartet
- die Struktur der Logbuch-Tabelle wird geändert, d.h. das Feld bzw. der Feldname mit der Versionsnummer wird umbenannt
- weitere Strukturänderungen werden durchgeführt
- das Update (Programmdateien) wird installiert
- der
DB-Server wird mit aktiviertem
TCP/
IP neu gestartet
Aufgrund Verwendung einer persistenten Feldliste können nun ältere Programmversionen generell nicht mehr am System angemeldet werden, weil ja das Feld (der Feldname) mit der neuen Versionsnummer bei der Anmeldung nicht gefunden wird. Die
Exception wird behandelt und der User darauf hingewiesen, dass er versucht hat, sich mit einer alten Programmversion am neuen Datenbestand anzumelden. Das funktioniert immer, sowohl bei lokalen auf dem Client liegenden Programmdateien als auch bei shared auf dem Server liegenden Programmdateien.