VonDoczuDoc.de

rfbdoc macht dies schon richtig!

Wenn 2 Kopierprozesse auf die DB zugreifen und einer ist fertig, dann würde die DB aus dem Backupmodus geholt, obwohl der erste Prozess noch läuft. Damit wäre die 2. Kopie inkonsistent und ggf. nicht vollständig, weil die DB dann nicht mehr lesbar ist. Deshalb it es sinnvoll, erst zu prüfen, ob nicht vielleicht gerade ein Skript / Nutzer von einer anderen Station backupt. Beim TMBACKUP Programm machen wir das auch so, allerdings etwas agressiver, wir beenden zunächst immer einen vorhandenen Backupmodus, der ja ggf. einen uralten Stand zur Sicherung bringt.

Kurze Nachfrage
Was bedeutet tumedprg im Befehl


%tumedprg%TMAdmin /beginBackup /server=%Servername%
?

Ist 'ne Variable für das TurboMed-Programmverzeichnis, z.B. "C:\TurboMed\Programm\".

Hallo,

EWERKER hat geschrieben:Wenn 2 Kopierprozesse auf die DB zugreifen und einer ist fertig, dann würde die DB aus dem Backupmodus geholt, obwohl der erste Prozess noch läuft...

Das leuchtet mir ein. Aber...
Wieso sollten zwei Kopierprozesse (=Datensicherungsaufgaben(?)) gleichzeitig auf den Server zugreifen?
Das würde ja heißen, dass man zwei Datensicherungen zeitgleich laufen lassen würde; also z.B. Sicherung gleichzeitig auf zwei andere Computer.
Warum sollte man das tun?
Ist das dann nicht eher das Ergebnis einer "unglücklichen" Konfiguration? "Hintereinander" wäre doch sinnvoller(?)

A. Geigenberger

Ist das dann nicht eher das Ergebnis einer "unglücklichen" Konfiguration? "Hintereinander" wäre doch sinnvoller(?)

Völlig korrrekt.
Da ich zeitgesteuert mittags meine Server automatisch synchronisiere kam es jedoch schon mal vor, dass ich zufällig zeitgleich auch noch manuell eine Synchronisierung ausgelöst habe, wie ich es täglich vor Verlassen der Praxis mache. Daher machte die Abfrage des externen Backupstatus in meiner Konfiguration Sinn. Gepostet habe ich es vor allem um zu beschreiben mit welch einfachen Bordmitteln dies zu realisieren ist.

Hallo,

ermutigt von diesem Thread habe ich mich heute daran gemacht, einen Client als Ersatzserver umzukonfigurieren.

Nach dem Rezept von Hr. Geigenberger habe ich folgendes getan:
1. Auf Client FastObject gestartet und als Dienst konfiguriert (hat funktioniert, der Dienst erscheint im Taskmanager nach Neustart des PC)
2. die Verzeichnisse PraxisDB, StammDB, Dokumente vom Server ins TM-Verzeichnis des Clients kopiert
3. aus der eigenen local.ini des Clients eine neue local.ini gebastelt durch Änderung der Zeilen wie angegeben (Mehrplatzbetrieb ja, Pfad t:\turbomed, Server localhost) und in einem neuen Verzeichnis gespeichert (t:\Ersatzserver\Server)
4. die originale local.ini des Clients ebenfalls in einem neuen Verzeichnis gespeichert (t:\Ersatzserver\Client)

Wenn ich nun die originale local.ini im TM-Verzeichnis durch die Server-local.ini ersetze erscheint beim TM-Start die Meldung "PraxisDict wird auf dem Computer nicht gefunden. Installieren Sie TM neu". Nach Rückkopieren der Client-local.ini startet der PC wieder ganz normal als Client.

Was habe ich da falsch gemacht?

Gruß

Fehlermeldung: Praxidict kann nicht gefunden werden
Diese Fehlermeldung erscheint u.a. wenn die Datei Ptserver.cfg nicht gefunden wird.
Als erstes überprüfen welcher FOS (32bit/64bit) läuft. Dann die Datei Ptserver.cfg in das entprechende Verzeichnis kopieren.
Standardmässig ist eine Ptserver.cfg im Verzeichnis TurboMed\Programm abgelegt. Der 32bit FOS greift darauf zu.
Für den 64bit FOS muss die Datei in das Verzeichnis \TurboMed\Programm\Fastobjects64\ verschoben werden

Hallo,

die Batch-Datei zur Datensicherung habe ich nochmals etwas umgeschrieben.
Falls jemand Interesse daran hat:
Hier können Sie sie finden:

http://www.vondoczudoc.de/viewtopic.php ... 045#p35045

Viele Grüße
A. Geigenberger

Hallo allerseits,

zur Farbgebung:
finde ich auch seit vielen Jahren wichtig, dabei verändere ich jedoch nicht nur die Hintergrundfarben des Hauptfensters und des Patientenfensters, sondern auch für die Karteikarte - Achtung: teils muss die "Fensterfarbe", für andere Bereiche die "Hintergrundfarbe" verändert werden.

Für die Umschaltung verwende ich z.T. noch mein Moduswechselsystem mit "Umschalter", sofern nur zwei Modi gewechselt werden - wenn aber mehr als zwei Modi verwendet werden (z.B. Client/Einzelplatz/Ersatz-Server), benutze ich seit langem das "allereinfachste Moduswechselsystem" von JRR.
Ist ja seit vielen Jahren alles im Wiki unter dem Stichwort "Moduswechsel" ausführlich beschrieben...

Zur Verhinderung zweier gleichzeitiger Zugriffe per TMAdmin-Backupmodus:
Die Abfrage-Routine von RFB finde ich sehr gut. Das läuft bei mir aber alles über "Geplante Tasks", und die zwei Rechner, die stündlich im Wechsel sich vom Server die DB kopieren, machen das eben einer zu geraden Stunden und der andere zu ungeraden Stunden. Da kommt sich keiner in die Quere. Die MFA habe damit bewußt nix zu tun... (ich kann aber per Desktopverknüpfung jederzeit selbst die Datenspiegelung auslösen).

Zum Verwenden von TMAdmin-Backup-Modus zum Kopieren der Datenbank im laufenden Betrieb:
Normalerweise darf TurboMed an dem "Ziel-Rechner" nicht gestartet sein, um die PraxisDB dort mit der aktuellen Version überschreiben zu können. Sofern man aber an dem Ort, an dem TurboMed die PraxisDB des Client-Rechners erwartet, nur eine auf die eigene Lizenz getrimmte Demo-DB stehen hat, läßt sich die Kopie der PraxisDB in einem speziell dafür vorgesehenen Verzeichnis (z.B. "TurboMed-EP-PraxisDB") auch dann einkopieren, wenn an dem betreffenden Rechner gerade aktiv mit TurboMed gearbeitet wird. Die Lokal.ini des Einzelplatz-Modus bzw. eines "Ersatz-Servers" hat dann genau dieses dafür eigens eingestellte Verzeichnis als Pfad für die PraxisDB eingestellt. Siehe im Wiki: "Datenspiegelung im Voll-Betrieb der Praxis"

Grüsse, Wahnfried

@wahnfried
"Normalerweise darf TurboMed an dem "Ziel-Rechner" nicht gestartet sein, um die PraxisDB dort mit der aktuellen Version überschreiben zu können. "

Der Zielrechner greift auf den Server zu und nicht auf die lokale PraxisDB. Insofern macht es m.E. nichts, wenn TM lokal gestartet ist bei der Spiegelung.

@wahnfried

....ich kann aber per Desktopverknüpfung jederzeit selbst die Datenspiegelung auslösen.

Und genau da könnten Sie mal einen laufenden zeitgesteuerten Task treffen, zumindest theroretisch...
Da die Abfrage des externen Backupstatus ja eigentlich leicht einzubauen ist kann man mit der Abfragesyntax (vermutlich eher theoretischen) Problemen vorbeugen.

@RAMöller

Der Zielrechner greift auf den Server zu und nicht auf die lokale PraxisDB. Insofern macht es m.E. nichts, wenn TM lokal gestartet ist bei der Spiegelung

Das sehe ich genauso, Wahnfried vermutlich ebenso.
Korrekt müsste es heissen:
"Normalerweise darf TurboMed an dem "Ziel-Rechner" nicht im Einzelplatzmodus gestartet sein, um die PraxisDB dort mit der aktuellen Version überschreiben zu können."

RAMöller hat geschrieben:@wahnfried
"Normalerweise darf TurboMed an dem "Ziel-Rechner" nicht gestartet sein, um die PraxisDB dort mit der aktuellen Version überschreiben zu können. "

Der Zielrechner greift auf den Server zu und nicht auf die lokale PraxisDB. Insofern macht es m.E. nichts, wenn TM lokal gestartet ist bei der Spiegelung.

Zumindest zur Zeit der Entwicklung des Systems "Datenspiegelung im Voll-Betrieb der Praxis" hat mein TurboMed-Client immer verlangt, am Zielrechner der Spiegelung beendet zu sein...

Das konnte ich durch o.a. Methode umgehen. Seitdem läuft das hier halt so

Grüsse, Wahnfried

rfbdoc hat geschrieben:@wahnfried

....ich kann aber per Desktopverknüpfung jederzeit selbst die Datenspiegelung auslösen.

Und genau da könnten Sie mal einen laufenden zeitgesteuerten Task treffen, zumindest theroretisch...

...deswegen benutzen die MFA diesen Button nie, sondern nur ich - aber extrem selten (und ich weiß, wann welche Sicherungsroutine läuft...)

Grüsse, Wahnfried