Unterschied Stamm DB udn Praxis DB
Moderator: Forum Moderatoren
Forumsregeln
TM-Startforum - "offen für alle Themen".
Beiträge, die in einen anderen Bereich passen, werden bei Bedarf verschoben.
TM-Startforum - "offen für alle Themen".
Beiträge, die in einen anderen Bereich passen, werden bei Bedarf verschoben.
-
- Beiträge: 292
- Registriert: Dienstag 6. Januar 2009, 20:16
- 15
- Hat sich bedankt: 17 times
Unterschied Stamm DB udn Praxis DB
Guten Tag!
Ich möchte mir einen Arbeitsplatz zum optionalen Notfallarbeitsplatz umbauen und diesen Notfall einmal
proben. Habe mir nun einen "Clone" vom Server erstellt (gleiche Hardware- Festplatte mit Acronis kopiert)
Zunächst habe ich all Eistellungen so vorgenommen (Compternamen von Server auf Arbeitsplatz XY)
geändert, IP Nummer geändert, Einstellungen in Grundeinstellung von Localhost zu Server ...., so dass
ich seit einigen Monaten diese Serverclone gut als Arbeitsplatz nutzen konnte. Hat 100%ig funktioniert.
Jetzt würde ich gerne mal den Ernstfall "Serverausfall" proben den Arbeitsplatz wieder zum Server
machen testweise, damit sich die anderen Arbeitsplätze auf ihm anmelden können. Ich spiegele jeden
Abend die Sicherung vom echten Server auf diesen Clone-Arbeitsplatz. Sollte nun heute einmal der Server
testweise ausfallen, müsste ich ja nachdem ich alles umgestellt habe noch die gespiegelte Objects.dat
des Servers und die Objects.idx logischerweise von gestern abend (die von Heute bekomme ich ja
im Falle eines Ausfalles nicht) noch in die entsprechenden Verzeichnisse sichern. Wenn ich das
dann gemacht habe kommt beim Start die Meldung, dass der Timestamp inconsistent
sei. Nun meine Fragen:
- Was bedeutet diese Fehlermeldeung?
- Was kann ich tun?
- Es gibt Objects.dat und idx imVerzichis "StammDB" und"Praxis DB": was ist der Unetrschied zwischen
Stamm und PRAXIS DB? Wo muss ich das reinkopieren?
Vielen Dank,
Charliechen
Ich möchte mir einen Arbeitsplatz zum optionalen Notfallarbeitsplatz umbauen und diesen Notfall einmal
proben. Habe mir nun einen "Clone" vom Server erstellt (gleiche Hardware- Festplatte mit Acronis kopiert)
Zunächst habe ich all Eistellungen so vorgenommen (Compternamen von Server auf Arbeitsplatz XY)
geändert, IP Nummer geändert, Einstellungen in Grundeinstellung von Localhost zu Server ...., so dass
ich seit einigen Monaten diese Serverclone gut als Arbeitsplatz nutzen konnte. Hat 100%ig funktioniert.
Jetzt würde ich gerne mal den Ernstfall "Serverausfall" proben den Arbeitsplatz wieder zum Server
machen testweise, damit sich die anderen Arbeitsplätze auf ihm anmelden können. Ich spiegele jeden
Abend die Sicherung vom echten Server auf diesen Clone-Arbeitsplatz. Sollte nun heute einmal der Server
testweise ausfallen, müsste ich ja nachdem ich alles umgestellt habe noch die gespiegelte Objects.dat
des Servers und die Objects.idx logischerweise von gestern abend (die von Heute bekomme ich ja
im Falle eines Ausfalles nicht) noch in die entsprechenden Verzeichnisse sichern. Wenn ich das
dann gemacht habe kommt beim Start die Meldung, dass der Timestamp inconsistent
sei. Nun meine Fragen:
- Was bedeutet diese Fehlermeldeung?
- Was kann ich tun?
- Es gibt Objects.dat und idx imVerzichis "StammDB" und"Praxis DB": was ist der Unetrschied zwischen
Stamm und PRAXIS DB? Wo muss ich das reinkopieren?
Vielen Dank,
Charliechen
-
- Beiträge: 113
- Registriert: Montag 7. Februar 2011, 12:47
- 13
Re: Unterschied Stamm DB udn Praxis DB
Inkonsistent timestamp bedeutet, dass objects.dat und objects.idx zeitlich nicht zusammen gehören.
Mit freundlichen Grüßen
Mit freundlichen Grüßen
-
- Beiträge: 292
- Registriert: Dienstag 6. Januar 2009, 20:16
- 15
- Hat sich bedankt: 17 times
Re: Unterschied Stamm DB udn Praxis DB
Aber was ist jetzt der Unterschied zwischen PraxisDB-Verzeichnis und der dortigen Objects.dat und der StammDB
und der Objects.dat in diesem Verzwichnis?
Bisher dachte ich, dass ich neben den oben genannten Aspekten nur die Objects.idx und die Obejects.dat, die
durch eine Datenspiegelung der Praxisdaten auf dem Server erzeugt wurden, in das TM verzeichnis eines Arbeitsplatzes in das
dortige Verzeichnis "PraxisDB" einkopieren muss, nach Löschen
(oder sicherheitshalber besser nur umbenennen) der dort vorhandenen Objects.dat bzw idx.
Somit hätte ich dann ja die Praxisdaten vom Server jetzt auf dem Arbeitsplatz und diesen nach Umstellen
aller anderen Parameter (siehe oben) zum Server gemacht mit den Daten der letzten aktuellen Spiegelung,
die ich ja auch schon bei meiner Spiegelungsmethode im eigenen Netzwerk in einem anderen Verzeichnis
bereits habe auf dem genannten Arbeitsplatz, der zum Notfallserver werden soll, habe.
Nun stolpere ich aber über die Stamm DB!! Mag ja eine blöde Frage sein: Aber was hat es mit dieser
StammDB auf sich? Bei mir befindet sich nicht nur in der PraxisDB, sondern auch in der Stamm DB eine
objects.dat und idx.... Also wo ist der Unterschied? Was macht die STammDB und was die PraxisDB
und was muss ich kopieren für mein Projekt? Muss ich außer der Speigelung der Praxisdaten aus der
Praxis DB auch noch die StammDB vom Server auf dem Notfall Server (ehemaliger Arbeitsplatz) einspielen?
Dann würde ja ein abendliches Spiegeln der Server-Praxisdaten nicht ausreichen, um im Notfall einen Notfallserver
aus einem Arbeitplatz zu bauen?
Mensch, jetzt habe ich es hinbekommen, aus einem Serverclone einen gut funktionierenden Abreitsplatz zu bauen, der
seit Monaten reibungslos funktioniert und immer schön die Spiegelung des echten Servers im Netzwerk
allabendlich empfängt, bekomme es aber nicht mehr hin aus dem nun als Arbeitsplatz laufenden PC mittels
dieser Spiegelung einen Notfallserver zu bauen. Ich denke es liegt daran, dass ich den Sinn und Zweck der
StammDB nicht begriffen habe und hier auch noch etwas einfügen muss?
und der Objects.dat in diesem Verzwichnis?
Bisher dachte ich, dass ich neben den oben genannten Aspekten nur die Objects.idx und die Obejects.dat, die
durch eine Datenspiegelung der Praxisdaten auf dem Server erzeugt wurden, in das TM verzeichnis eines Arbeitsplatzes in das
dortige Verzeichnis "PraxisDB" einkopieren muss, nach Löschen
(oder sicherheitshalber besser nur umbenennen) der dort vorhandenen Objects.dat bzw idx.
Somit hätte ich dann ja die Praxisdaten vom Server jetzt auf dem Arbeitsplatz und diesen nach Umstellen
aller anderen Parameter (siehe oben) zum Server gemacht mit den Daten der letzten aktuellen Spiegelung,
die ich ja auch schon bei meiner Spiegelungsmethode im eigenen Netzwerk in einem anderen Verzeichnis
bereits habe auf dem genannten Arbeitsplatz, der zum Notfallserver werden soll, habe.
Nun stolpere ich aber über die Stamm DB!! Mag ja eine blöde Frage sein: Aber was hat es mit dieser
StammDB auf sich? Bei mir befindet sich nicht nur in der PraxisDB, sondern auch in der Stamm DB eine
objects.dat und idx.... Also wo ist der Unterschied? Was macht die STammDB und was die PraxisDB
und was muss ich kopieren für mein Projekt? Muss ich außer der Speigelung der Praxisdaten aus der
Praxis DB auch noch die StammDB vom Server auf dem Notfall Server (ehemaliger Arbeitsplatz) einspielen?
Dann würde ja ein abendliches Spiegeln der Server-Praxisdaten nicht ausreichen, um im Notfall einen Notfallserver
aus einem Arbeitplatz zu bauen?
Mensch, jetzt habe ich es hinbekommen, aus einem Serverclone einen gut funktionierenden Abreitsplatz zu bauen, der
seit Monaten reibungslos funktioniert und immer schön die Spiegelung des echten Servers im Netzwerk
allabendlich empfängt, bekomme es aber nicht mehr hin aus dem nun als Arbeitsplatz laufenden PC mittels
dieser Spiegelung einen Notfallserver zu bauen. Ich denke es liegt daran, dass ich den Sinn und Zweck der
StammDB nicht begriffen habe und hier auch noch etwas einfügen muss?
-
- PowerUser
- Beiträge: 2924
- Registriert: Sonntag 30. April 2006, 19:31
- 17
- Hat sich bedankt: 29 times
- Bedankt: 51 times
Re: Unterschied Stamm DB und Praxis DB
Ignorieren Sie einfach das komplette Verzeichnis StammDB !!!!!
Für den Moduswechsel Client->Server kopieren Sie das komplette Verzeichnis PraxisDB vom Server auf den Clienten am besten mit dem Befehl robocopy /mir. Starten Sie den FOS (oder lassen den Dienst einfach immer auch auf dem Clienten laufen, der beeinträchtigt die Performance überhaupt nicht) und passen jetzt nur noch die Grundeinstellungen des localen Clienten an.
Der Modus Client/Server wird ausschliesslich über local.ini und global.ini gesteuert.
Kopieren Sie sich einfach in einen Ordner C:\TmConf mit Unterordner Clientmodus und Servermodus eine entsprechend angepasste local.ini und global.ini, erstellen sich dann auf dem Desktop zwei neue TurboMed Verknüpfungen zur lokalen TurboMed.exe und geben dort im Feld "Ausführen in" den Pfad C:\TmConf\Clientmodus bzw. C:\TmConf\Servermodus ein.
Für den Moduswechsel Client->Server kopieren Sie das komplette Verzeichnis PraxisDB vom Server auf den Clienten am besten mit dem Befehl robocopy /mir. Starten Sie den FOS (oder lassen den Dienst einfach immer auch auf dem Clienten laufen, der beeinträchtigt die Performance überhaupt nicht) und passen jetzt nur noch die Grundeinstellungen des localen Clienten an.
Der Modus Client/Server wird ausschliesslich über local.ini und global.ini gesteuert.
Kopieren Sie sich einfach in einen Ordner C:\TmConf mit Unterordner Clientmodus und Servermodus eine entsprechend angepasste local.ini und global.ini, erstellen sich dann auf dem Desktop zwei neue TurboMed Verknüpfungen zur lokalen TurboMed.exe und geben dort im Feld "Ausführen in" den Pfad C:\TmConf\Clientmodus bzw. C:\TmConf\Servermodus ein.
R.F.B.
-
- Beiträge: 516
- Registriert: Dienstag 7. Oktober 2008, 13:56
- 15
- Wohnort: 91463 Dietersheim
Re: Unterschied Stamm DB udn Praxis DB
Hallo,Charliechen hat geschrieben:Aber was ist jetzt der Unterschied zwischen PraxisDB-Verzeichnis und der dortigen Objects.dat und der StammDB
und der Objects.dat in diesem Verzwichnis? ...
Die StammDB enthält nichts praxisspezifisches, sondern eben "Stamm"daten, wie z.B. die Gebührenordnungsstämme, Diagnosenstamm, Kostenträgerstamm, etc. Diese DB ändert sich nie im Betrieb, wird nur beim Update aktualisiert, solte auf jedem TM-Rechner in ganz Deutschland (bei gleicher TM-Version) dasselbe enthalten.
Diese StammDB brauchen Sie also nicht kopieren, wenn Sie den Server tauschen wollen.
Die PraxisDB enthält Ihre spezifischen Daten, wie Patientenkartei, Laborwerte, Privatrechnungen, sämtliche "eigenen" Listen, etc.
Diese DB müssen Sie also Kopieren.
Dabei aber nie einzelne Dateien, sondern das komplette Verzeichnis PraxisDB kopieren!
(jede einzelne Fastobjects-Datenbank besteht nicht nur aus den Dateien objects.dat (Daten) und objects.idx (Indizes), sondern aus weiteren Unterordnern mit weiteren Dateien für Backupmodus und Recovery.
Wenn Sie da nicht alles kopieren, entstehen Inkonsistenzen wie etwa Timestamp-Fehler.
Im übrigen dürfen Sie nicht vergessen, weitere spezifische Daten zu kopieren (insbes. die Verzeichnisse Dokumente, KVDT, evtl. auch Formulare).
Gruß
FranzKonrad
-
- Beiträge: 292
- Registriert: Dienstag 6. Januar 2009, 20:16
- 15
- Hat sich bedankt: 17 times
Re: Unterschied Stamm DB udn Praxis DB
Ok danke!
Ich habe wohl Stamm DB udn PraxisDB verwechselt, was den Fehler hervorgerufen hat.
Jetzt klappt es wunderbar! Habe den Server runtergefahren und auch die sonstigen
Arbeitsplätze ausgeschaltet. Dann den genannten Arbeitsplatz "zum Server"
gemacht udn hier Fastobjects gestartet. Danach alle Arbeitsplätze wieder hochgefahren
(bis auf den alten Server natürlich- der blieb aus, weil ersoll ja mal so tun, als sei er defekt)
Ich konnte wunderbar arbeiten, als wäre nichts gewesen.
Natürlich ganz ohne "Dokumente", da ein Rückspielen der ganzen Dokumente von
10 jahren auch im Notfall zu lange dauert. Dann alles wieder rückgängig gemacht,
alles wieder augeschaltet, den alten Server hochgefahren und schon war der Notfall
server wieder ein normaler Arbeitsplatz. So muss das klappen im Notfall!
Ich würde es dann so machen, wenn es einen Serverausfall geben sollte:
1) Den o.g. Arbeitsplatz zum Server machen udn die letzte Datenspiegelung dort
einkopieren (Ich mache immer mit der Turbomed Praxisdatensicherung abends eine
Spiegelung der Praxisdaten auch auf den o.g. Arbeitsplatz im Netzwerk- dann
habe ich ja nur die Datein aus der PraxisDB auf diesem Arbeitsplatz im Spiegelungsverzeichnis).
Bei Daten vom Vorabend (Zeitpunkt der letzten Spiegelung) fehlen dann die Daten vom Morgen bis
zum Ausfall ja noch. Darauf muss man dann erst einmal verzichten!
2) Nach dem Notfallbetrieb würde ich natürlich versuchen irgendwie den echten alten Server
wieder in Gang zu setzen, z.B. in der Mittagspause. Sollte ich das nicht hinbekommen,
würde ich die Festplatte mit den Dokumenten (Ich habe ein Laufwerk F:\ im
Server nur für Dokumente) aus dem Server ausbauen und per USB adapter (da gibt
es solche Sets mit Stromadapter für 220V und uSB Stecker- funktioniert super:
schon probiert!) an den Notfallsever auch als F:\ anschließen. Dann hätte ich ganz
schnell ab der Mittagspase auch wieder die Dokumente. Ich würde aber die Helferinnen anweisen,
bis zur Reparatur des alten Server keine Dokumente mehr einzuscannen und alle Originale
zu sammeln. Sollte gerade diese Platte F auch defekt sein, müsste ich die Dokumente aus
der Acronis-Sicherung der Vornacht alle auslesen und per Acronis einen Festplatten-Clone
über Nacht herstellen. Das dauert sehr lange, bei großen Festplatten mit Dokumenten
von 10 Jahren. Mache ich aber auch regelmäßig auf einem weiteren Rechner zu Hause,
da es beruhigend ist, nicht nur gepackteSicherungen zu haben, sondern ab und zu mal
auchlaufende Funktionierende Parallel-Systeme.
3) Wenn dann irgendwan (hoffentlich innerhalb einer Woche) der Server wieder repariert
wurde, hätte dieser dann ja den Datenstand von vor dem Ausfall. Aber auch der Notfall-
server hätte nicht alle Daten: Darüber muss man sich klar sein!!! Ihm fehlen ja die Daten
vom Morgen bis zum Ausfallzeitpunkt !!! (siehe oben)-
Praxisdaten vom Notfallserver auf den reparierten echten Server spiegeln udn diese
Daten dann ich echten Server enkopieren- wäre also keine Lösung!!
Also müsste ich die Patienten, die während des Notfallbetriebes in der
Praxis waren, per Hausbesuchsmodul aus dem Notfallserver auslesen und dann auf
dem raparieten Server wieder einlesen. Dann die DokumentenFestplatte
wieder in den alten Server einbauen und alle gesammelten Originaldokumente der Zwischenzeit
scannen lassen. So wäre auf dem echten Server alles wieder auf dem akuellen Stand.
Auf jeden Fall hätte ich so blitzschnell eine Lösung vor Augen bei rappelvoller Praxis
im Notfall erst einmal weiterzuarbeiten ohne irgendwelche Daten zu verlieren!
Ich habe wohl Stamm DB udn PraxisDB verwechselt, was den Fehler hervorgerufen hat.
Jetzt klappt es wunderbar! Habe den Server runtergefahren und auch die sonstigen
Arbeitsplätze ausgeschaltet. Dann den genannten Arbeitsplatz "zum Server"
gemacht udn hier Fastobjects gestartet. Danach alle Arbeitsplätze wieder hochgefahren
(bis auf den alten Server natürlich- der blieb aus, weil ersoll ja mal so tun, als sei er defekt)
Ich konnte wunderbar arbeiten, als wäre nichts gewesen.
Natürlich ganz ohne "Dokumente", da ein Rückspielen der ganzen Dokumente von
10 jahren auch im Notfall zu lange dauert. Dann alles wieder rückgängig gemacht,
alles wieder augeschaltet, den alten Server hochgefahren und schon war der Notfall
server wieder ein normaler Arbeitsplatz. So muss das klappen im Notfall!
Ich würde es dann so machen, wenn es einen Serverausfall geben sollte:
1) Den o.g. Arbeitsplatz zum Server machen udn die letzte Datenspiegelung dort
einkopieren (Ich mache immer mit der Turbomed Praxisdatensicherung abends eine
Spiegelung der Praxisdaten auch auf den o.g. Arbeitsplatz im Netzwerk- dann
habe ich ja nur die Datein aus der PraxisDB auf diesem Arbeitsplatz im Spiegelungsverzeichnis).
Bei Daten vom Vorabend (Zeitpunkt der letzten Spiegelung) fehlen dann die Daten vom Morgen bis
zum Ausfall ja noch. Darauf muss man dann erst einmal verzichten!
2) Nach dem Notfallbetrieb würde ich natürlich versuchen irgendwie den echten alten Server
wieder in Gang zu setzen, z.B. in der Mittagspause. Sollte ich das nicht hinbekommen,
würde ich die Festplatte mit den Dokumenten (Ich habe ein Laufwerk F:\ im
Server nur für Dokumente) aus dem Server ausbauen und per USB adapter (da gibt
es solche Sets mit Stromadapter für 220V und uSB Stecker- funktioniert super:
schon probiert!) an den Notfallsever auch als F:\ anschließen. Dann hätte ich ganz
schnell ab der Mittagspase auch wieder die Dokumente. Ich würde aber die Helferinnen anweisen,
bis zur Reparatur des alten Server keine Dokumente mehr einzuscannen und alle Originale
zu sammeln. Sollte gerade diese Platte F auch defekt sein, müsste ich die Dokumente aus
der Acronis-Sicherung der Vornacht alle auslesen und per Acronis einen Festplatten-Clone
über Nacht herstellen. Das dauert sehr lange, bei großen Festplatten mit Dokumenten
von 10 Jahren. Mache ich aber auch regelmäßig auf einem weiteren Rechner zu Hause,
da es beruhigend ist, nicht nur gepackteSicherungen zu haben, sondern ab und zu mal
auchlaufende Funktionierende Parallel-Systeme.
3) Wenn dann irgendwan (hoffentlich innerhalb einer Woche) der Server wieder repariert
wurde, hätte dieser dann ja den Datenstand von vor dem Ausfall. Aber auch der Notfall-
server hätte nicht alle Daten: Darüber muss man sich klar sein!!! Ihm fehlen ja die Daten
vom Morgen bis zum Ausfallzeitpunkt !!! (siehe oben)-
Praxisdaten vom Notfallserver auf den reparierten echten Server spiegeln udn diese
Daten dann ich echten Server enkopieren- wäre also keine Lösung!!
Also müsste ich die Patienten, die während des Notfallbetriebes in der
Praxis waren, per Hausbesuchsmodul aus dem Notfallserver auslesen und dann auf
dem raparieten Server wieder einlesen. Dann die DokumentenFestplatte
wieder in den alten Server einbauen und alle gesammelten Originaldokumente der Zwischenzeit
scannen lassen. So wäre auf dem echten Server alles wieder auf dem akuellen Stand.
Auf jeden Fall hätte ich so blitzschnell eine Lösung vor Augen bei rappelvoller Praxis
im Notfall erst einmal weiterzuarbeiten ohne irgendwelche Daten zu verlieren!
-
- PowerUser
- Beiträge: 2924
- Registriert: Sonntag 30. April 2006, 19:31
- 17
- Hat sich bedankt: 29 times
- Bedankt: 51 times
Re: Unterschied Stamm DB udn Praxis DB
Sie können das so machen, da sie ja exakt wissen, welche Daten auf welcher Festplatte sind.
Ich mache es etwas anders. Über Robocopy /mir Befehle werden Server und Ersatzsserver regelmässig synchronisiert, das geht ja bei regelmässiger Spiegelung schneller als einen Schraubenzieher zu suchen, da ja jeweils nur die Differenzdaten kopiert werden.
Am Beginn der Mittagspause und abends beim Verlassen der Praxis sind bei mir die Datenbestände auf beiden Servern identisch, und zwar die von allen (!) Daten.
Sollte wirklich ein Server ausfallen wird auf den anderen umgestellt und weiter gearbeitet einschliesslich Scannen von Dokumenten und allen anderen Praxistätigkeiten. Zugleich werden alle Daten die von der letzten Serverspiegelung bis zum Ausfall des Servers angefallen sind tagesaktuell manuell auf dem Ersatzsystem nachgetragen, man glaubt garnicht was die Helferinnen tagesaktuell noch aus dem Kopf nachtragen können, und die gescannten Berichte sind dann ohnehin noch nicht im Schredder. Dann wird einfach auf dem Ersatzserver weiter gearbeitet mit kompletten Datenbestand.
Theoretisch könnte man auch stündlich batchgesteuert synchronisieren, dann müsste weniger händisch nachgearbeitet werden. Mir reicht es mit 2x täglich unter meinen Praxisbedingungen aus. Großpraxen können sicher mit einer solchen Lösung nicht arbeiten, aber in einer überschaubaren Einzelpraxis sieht das anders aus.
Nach Instandsetzung des Hauptservers würde später alles zurückgespiegelt. Zum Glück ist der worst case bisher noch nicht dagewesen, ab es ist ein sehr beruhigendes Gefühl dafür gewappnet zu sein.
Ich mache es etwas anders. Über Robocopy /mir Befehle werden Server und Ersatzsserver regelmässig synchronisiert, das geht ja bei regelmässiger Spiegelung schneller als einen Schraubenzieher zu suchen, da ja jeweils nur die Differenzdaten kopiert werden.
Am Beginn der Mittagspause und abends beim Verlassen der Praxis sind bei mir die Datenbestände auf beiden Servern identisch, und zwar die von allen (!) Daten.
Sollte wirklich ein Server ausfallen wird auf den anderen umgestellt und weiter gearbeitet einschliesslich Scannen von Dokumenten und allen anderen Praxistätigkeiten. Zugleich werden alle Daten die von der letzten Serverspiegelung bis zum Ausfall des Servers angefallen sind tagesaktuell manuell auf dem Ersatzsystem nachgetragen, man glaubt garnicht was die Helferinnen tagesaktuell noch aus dem Kopf nachtragen können, und die gescannten Berichte sind dann ohnehin noch nicht im Schredder. Dann wird einfach auf dem Ersatzserver weiter gearbeitet mit kompletten Datenbestand.
Theoretisch könnte man auch stündlich batchgesteuert synchronisieren, dann müsste weniger händisch nachgearbeitet werden. Mir reicht es mit 2x täglich unter meinen Praxisbedingungen aus. Großpraxen können sicher mit einer solchen Lösung nicht arbeiten, aber in einer überschaubaren Einzelpraxis sieht das anders aus.
Nach Instandsetzung des Hauptservers würde später alles zurückgespiegelt. Zum Glück ist der worst case bisher noch nicht dagewesen, ab es ist ein sehr beruhigendes Gefühl dafür gewappnet zu sein.
R.F.B.
-
- Beiträge: 117
- Registriert: Sonntag 22. Mai 2005, 09:07
- 18
- Wohnort: Dachau
- Bedankt: 1 time
- Kontaktdaten:
Re: inconsistent timestamp
Der Fehler "inconsistent timestamp" bedeutet nicht, dass StammDB und PraxisDB nicht zusammengehören.
Eine Beschreibung des Fehlers fand ich untenstehend in einem FastObjects-Handbuch.
Bei mir half, in den Verzeichnissen PraxisDB, StammDB und DruckDB und den jeweiligen Backup-Unterordnern alle recovery-Ordner (also 6 Stück) umzubenennen. Beim nächsten Start von Turbomed frägt er dann, ob er auf die Recovery-Daten verzichten solle (was bejaht werden müßte) und erstellt dann die recovery-Verzeichnisse neu.
Viele Grüße, Gerald Schade
-2614
ERR_PT_FILE_INCONSISTENT_TIMESTAMPS
One of the database files has an inconsistent timestamp and the database cannot be opened.
You can usually resolve this problem by performing the following steps:
1. Forcefully disable recovery
2. Try to open the database.
3. If the error still oc curs, reinde x the database.
4. Re-enable rec o v er y .
Y ou may also find the f ollo wing detailed inf ormation useful. The data file (objec ts.dat), the inde x file (objec ts.idx) and the rec o v er y file (data0000.rcy , b y default in subf older " rec o v er y") c ontain a creation and modification timestamp. These timestamps are used to check whether these files fit together . If one of the timestamps does no t match the o thers, the database canno t be opened, in which case this error c ode is returned. Generation of this error c ode pre v ents the database from being damaged as the result of an outdated rec o v er y file or non-matching inde x file. A c ommon sc enario f or a non-matching rec o v er y file is when y ou open a backup of a database that was created during e xternal backup. If y ou c op y the database files while e xternal backup is running, y ou hav e to c onsider whether the rec o v er y file should be part of the backup. For a snapsho t of the database, do no t c op y the rec o v er y file. If y ou restore the backup of the database to the same location, the rec o v er y f older of the o v er writ ten database might remain. A subsequent opening of the database will check the timestamps and determine that the modification timestamp of the rec o v er y file is ne w er than the modification timestamp of bo th database files. Error -2614 will be returned. In this sc enario it is saf e to f orc efully turn off rec o v er y because the database was intended to be a snapsho t and, more important, the rec o v er y file does no t match the database. Y ou can do this b y using forceDisableRecovery with the PtADMIN c ommand line tool, from either the Java binding or C++ binding. For a step-b y -step descrip tion, ref er to the FastObjects A dministration Guide .
Eine Beschreibung des Fehlers fand ich untenstehend in einem FastObjects-Handbuch.
Bei mir half, in den Verzeichnissen PraxisDB, StammDB und DruckDB und den jeweiligen Backup-Unterordnern alle recovery-Ordner (also 6 Stück) umzubenennen. Beim nächsten Start von Turbomed frägt er dann, ob er auf die Recovery-Daten verzichten solle (was bejaht werden müßte) und erstellt dann die recovery-Verzeichnisse neu.
Viele Grüße, Gerald Schade
-2614
ERR_PT_FILE_INCONSISTENT_TIMESTAMPS
One of the database files has an inconsistent timestamp and the database cannot be opened.
You can usually resolve this problem by performing the following steps:
1. Forcefully disable recovery
2. Try to open the database.
3. If the error still oc curs, reinde x the database.
4. Re-enable rec o v er y .
Y ou may also find the f ollo wing detailed inf ormation useful. The data file (objec ts.dat), the inde x file (objec ts.idx) and the rec o v er y file (data0000.rcy , b y default in subf older " rec o v er y") c ontain a creation and modification timestamp. These timestamps are used to check whether these files fit together . If one of the timestamps does no t match the o thers, the database canno t be opened, in which case this error c ode is returned. Generation of this error c ode pre v ents the database from being damaged as the result of an outdated rec o v er y file or non-matching inde x file. A c ommon sc enario f or a non-matching rec o v er y file is when y ou open a backup of a database that was created during e xternal backup. If y ou c op y the database files while e xternal backup is running, y ou hav e to c onsider whether the rec o v er y file should be part of the backup. For a snapsho t of the database, do no t c op y the rec o v er y file. If y ou restore the backup of the database to the same location, the rec o v er y f older of the o v er writ ten database might remain. A subsequent opening of the database will check the timestamps and determine that the modification timestamp of the rec o v er y file is ne w er than the modification timestamp of bo th database files. Error -2614 will be returned. In this sc enario it is saf e to f orc efully turn off rec o v er y because the database was intended to be a snapsho t and, more important, the rec o v er y file does no t match the database. Y ou can do this b y using forceDisableRecovery with the PtADMIN c ommand line tool, from either the Java binding or C++ binding. For a step-b y -step descrip tion, ref er to the FastObjects A dministration Guide .
Gerald Schade, Mittermayerstraße 13, 85221 Dachau, Tel. 08131 616380
-
- Beiträge: 242
- Registriert: Dienstag 14. Juli 2020, 13:26
- 3
- Hat sich bedankt: 26 times
- Bedankt: 5 times
Re: Unterschied Stamm DB udn Praxis DB
Interessante Ideen für einen Notfallserver, ich habe aber eine Terminalserver-Installation. Kann ich da so etwas ähnliches auch machen ?
-
- Beiträge: 117
- Registriert: Sonntag 22. Mai 2005, 09:07
- 18
- Wohnort: Dachau
- Bedankt: 1 time
- Kontaktdaten:
Re: Unterschied Stamm DB udn Praxis DB
@Nervenarzt:
Ja, bei der Datensicherung kann man sich ja mehrere Funktionsgesichtspunkte vorstellen:
1) dass im Fall einer Schädigung des Servers oder Verschlüsselung seiner Daten dieselben überhaupt noch irgendwo sind,
2) dass man in einem solchen Fall auch möglichst bald mit der Sprechstunde weitermachen könnte.
Um beides bereitzustellen, würde sich bei einer Terminal-Server-Installation z.B. die Hinzunahme eines zusätzlichen Reserveservers anbieten, auf den alles Wichtige außer der Ransomware und anderen Viren regelmäßig oder automatisch kopiert wird.
Ja, bei der Datensicherung kann man sich ja mehrere Funktionsgesichtspunkte vorstellen:
1) dass im Fall einer Schädigung des Servers oder Verschlüsselung seiner Daten dieselben überhaupt noch irgendwo sind,
2) dass man in einem solchen Fall auch möglichst bald mit der Sprechstunde weitermachen könnte.
Um beides bereitzustellen, würde sich bei einer Terminal-Server-Installation z.B. die Hinzunahme eines zusätzlichen Reserveservers anbieten, auf den alles Wichtige außer der Ransomware und anderen Viren regelmäßig oder automatisch kopiert wird.
Gerald Schade, Mittermayerstraße 13, 85221 Dachau, Tel. 08131 616380
Wer ist online?
Mitglieder in diesem Forum: Bing [Bot] und 91 Gäste