Plötzlich: Fehlermeldung Lizenz (dringend!)

[nmndoc]

Hallo,

gestern rief mich die Mitarbeiterin einer Praxis an: nachdem sie die Datensicherung gemacht hatte, kam auf einmal ein Fenster dass die aktive Lizenz nicht zur Datenbank passen würde (siehe Screenshot). Beim Fortfahren würde die DB angepasst etc!?
Wo kommt auf einmal die Meldung her? Leider tritt das auch auf dem Server auf. Einfach "ok" zu klicken scheint mir falsch zu sein...
Wie kann ich feststellen, welche Lizenzinformationen in der DB sind? Oder kann ich doch ok klicken, wenn ich mir sicher bin dass die aktuelle XML-Lizenz die richtige ist?

[michael]

Hallo,

gestern rief mich die Mitarbeiterin einer Praxis an: nachdem sie die Datensicherung gemacht hatte, kam auf einmal ein Fenster dass die aktive Lizenz nicht zur Datenbank passen würde (siehe Screenshot). Beim Fortfahren würde die DB angepasst etc!?

Unbedingt vorher eine Datensicherung machen!!!!!!

Bisher war es so, dass nachdem man auf ok geklickt hat nochmal eine Auswahl kam welche Lizenz gegen welche ausgetauscht wird.

Vorher würde ich aber nochmal nachsehen, ob die Clients mit dem Server Verbindung aufnehmen. wenn sie TM auf dem Client aufrufen, haben sie dann eine Lizensierte oder eine Demoversion?
Ist die Lizenzdatei noch vorhanden?
Stimmen die Zugriffsrechte??

Viel Erfolg

M. Pätzold

[nmndoc]

Hallo,

der fehler kommt sowohl auf dem Client, als auch auf dem Server (leider).
Ich habe testweise mal die praxisdb vom 15.11. eingespielt (Fehler trat 16.11. abends auf) - und siehe da - keine Fehlermeldung von wegen der Lizenz (also ohne dass ich etwas an der Lizenzdatei geändert hätte).
Im Startbildschirm unter "Lizenziert für..." sieht die Anzeige eigentlich gleich aus (Namen der Ärzte) - aber evtl. heisst das nichts.

Leider sind gerade nur 1 Client und der Server an (bin remote drauf). Da die Clients offenbar so eingestellt sind (d.h ich vermute es), dass sie die Lizenz NICHT zuerst auf auf dem Server suchen, frage ich mich, ob evtl. ein Client - aus welchen Gründen auch immer eine falsche Lizenz lokal hatte - und dann eine Mitarbeiterin die DB konvertiert hat? Ich befürchte leider, dass der Fehler auch in der Sichrung vom 16. schon drin ist - also wäre ein tag pfutsch? oder könnte man die Änderungen des Tages irgendwie exportieren und dann wieder importieren?

Angenommen ich entscheide mich, bei o.g. Meldung auf ok zu klicken/ die Lizenz zu ersetzen - woran sehe ich dann ob das Ergebnis ok ist? (bzw. welche Konseqzenzen hat der Tausch einer Lizenz?)

[Lazarus]

Wenn die Dantenbank vom 15.11. noch funktioniert, kann es eigentlich nicht an der Lizenz liegen. Ansonsten müsste der Fehler weiterbestehen.

Mich würde interessieren, was am 16.11 gesichert wurde. (Können sie auf einem eigenen Rechner die Daten probeweise rücksichern, und auf welchen Namen laufen sie dann?)

Der Fehler trat nach der Sicherung auf. Vielleicht kann man die Daten dann noch retten per BDT Einzelexport.

Möglich ist, dass der Client nach der Sicherung den Kontakt zum Server verloren hatte, dann beim Erneuten Start auf Dr. Mustermann umgestellt hatte und die Datenbank konvertieren wollte bzw. dabei unterbrochen wurde. Allerdings könnte man denoch die Daten manuell übertragen.

Wenn der Server schon etwas älter ist, wäre ein Hardware-Wechsel zu überlegen. Vielleich auch beim Client.

Grüße
Lazarus

[wahnfried]

Hallo,

der fehler kommt sowohl auf dem Client, als auch auf dem Server (leider).
Ich habe testweise mal die praxisdb vom 15.11. eingespielt (Fehler trat 16.11. abends auf) - und siehe da - keine Fehlermeldung von wegen der Lizenz (also ohne dass ich etwas an der Lizenzdatei geändert hätte).
Im Startbildschirm unter "Lizenziert für..." sieht die Anzeige eigentlich gleich aus (Namen der Ärzte) - aber evtl. heisst das nichts.

Leider sind gerade nur 1 Client und der Server an (bin remote drauf). Da die Clients offenbar so eingestellt sind (d.h ich vermute es), dass sie die Lizenz NICHT zuerst auf auf dem Server suchen, frage ich mich, ob evtl. ein Client - aus welchen Gründen auch immer eine falsche Lizenz lokal hatte - und dann eine Mitarbeiterin die DB konvertiert hat? Ich befürchte leider, dass der Fehler auch in der Sichrung vom 16. schon drin ist - also wäre ein tag pfutsch? oder könnte man die Änderungen des Tages irgendwie exportieren und dann wieder importieren?

Angenommen ich entscheide mich, bei o.g. Meldung auf ok zu klicken/ die Lizenz zu ersetzen - woran sehe ich dann ob das Ergebnis ok ist? (bzw. welche Konseqzenzen hat der Tausch einer Lizenz?)

Hallo nmndoc,

wenn Sie auf den Clients eine reine Arbeitsplatzinstallation haben, gibt es dort keine Lizenz, es sei denn, Sie hätten diese mal 'rüberkopiert. Wenn Sie die Clients Einzelplatz-fähig aufgebaut haben (Hausbesuchsrechner oder moduswechselnder Rechner), haben Sie sowohl PraxisDB als auch Lizenz auf den Client kopiert, bevor Sie dort TurboMed erstmals gestartet haben.

Wenn Sie bereits einen Lizenz-Ordner mit einer XML-Datei als Lizenz haben, hätten Sie sicher längst den Inhalt dieser Lizenzdatei kontrolliert, da im Browser klartext-lesbar. Insofern denke ich, daß SIe noch mit einer BINTAB.DAT-Lizenz arbeiten. Dann würde ich das Datum "letzte Änderung" dieser Datei und deren hash-Wert mit den Angaben zur BINTAB.DAT aus der letzten Gesamt-Datensicherung der TurboMed-enthaltenden Partition vergleichen. Wenn Unterschiede auffallen, benennen SIe die BINTAB.DAT auf Server und Client um, ersetzen diese durch die aus der letzten Komplett-DaSi und schauen, ob der Fehler wieder auftritt.

Fehlerbehebung auf jeden Fall auf einem Einzelplatzrechner üben. Für die Lizenz-Neu-Einspielung benötigen Sie ein Tagespasswort, daher kann das die Helferin nicht versehentlich gemacht haben. Insofern vermute ich eine korrumpierte Datei als Ursache des Fehlers (das bedeutet, wenn die Lizenzdatei nicht korrumpiert ist, müßte es die PraxisDB sein!). Testweise können Sie das von Frau Ramm hier für Sept.2010 (?) mitgeteilte Tagespasswort nehmen und für Eingabe und Bestätigung des Tagespasswortes kurz das Systemdatum auf den entsprechenden Tag umstellen. Anschließend die PraxisDB auf dem Einzelplatz nach Strich und Faden testen...

Wie oben bereits von michael gepostet: Derzeitige fehlerproduzierende PraxisDB auf der Windows-Ebene verifiziert kopieren (besser mehrfach), sofern Sie TurboMed wegen der Fehlermeldung nicht mehr in der Praxis starten können. Dann die Behebung (falls Lizenzkopie aus Dasi nicht hilft) mit dieser Datenbankkopie auf Einzelplatz üben...

Viel Glück, Wahnfried

[nmndoc]

Hallo,

es handelt sich tatsächlich schon um eine XML-datei. Da ja die Datenbank vom 15.11. mit der selben Lizenz nicht den Fehler bringt, vermute ich mal dass die Lizenz an sich in Ordnung ist. (und ja: auf dem Client ist kein Lizenz-Ordner - zumindest nicht auf dem, auf dem ich nachesehen kann). Mit der Kontrolle der Lizenzdatei ist es so eine Sache - aber soweit ich es beurteilen kann müsste das passen - zumal ja mit der DB vom 15. nicht der Fehler auftritt (s.o).

Also dann wohl doch ein Fehler in der DB?

[nmndoc]

Nachtrag: Was bedeutet "nach Strich und Faden" testen? Können Sie mit konkrete Punkte nennen, die überprüft werden müssen (ausser natürlich ob die Daten vom Freitag noch da sind)

[wahnfried]

Hallo,

gestern rief mich die Mitarbeiterin einer Praxis an: nachdem sie die Datensicherung gemacht hatte, kam auf einmal ein Fenster dass die aktive Lizenz nicht zur Datenbank passen würde (siehe Screenshot). Beim Fortfahren würde die DB angepasst etc!?
...
Wie kann ich feststellen, welche Lizenzinformationen in der DB sind? Oder kann ich doch ok klicken, wenn ich mir sicher bin dass die aktuelle XML-Lizenz die richtige ist?

...Vielleicht noch überprüfen, ob der Fehler weg ist, wenn man Server und Client der Praxis neu startet.

Habe doch überlesen, daß Sie ja mitgeteilt haben, eine XML-Lizenz zu benutzen. Auch hier würde ich deren hash-Wert mit der Version aus einer Partitions-Sicherung mit TurboMed überprüfen, ansonsten den Inhalt auf Fehler in der Schreibweise der Praxisdaten kontrollieren, falls ein Unterschied beim hash-Wert festgestellt wird. Dann aber noch: gibt es auf den Rechnern auch noch die Bintab.Dat von früher?? Falls dann der Zugriff auf die XML-Lizenz nicht gelingt, versucht TurboMed nämlich, die Bintab.Dat zu benutzen - und die dürfte dann nicht mehr passen... (also ggfs vorhandene Bintab.dat mal umbenennen...).

Lazarus hat m.E. recht, wenn er meint, die Lizenz müsse ok sein, wenn die Datenrücksicherung des 15.11. funktioniert. Trotzdem würde ich die Lizenzdatei auf Nicht-Korrumpierung prüfen. Ansonsten wäre das ein Hinweis auf eine korrumpierte PraxisDB.

Wenn die TurboMed-interne DaSi des 16.11. (die ja alle Praxisdaten enthalten sollte) auch fehlerfrei läuft, würde ja sogar eine Datenrücksicherung ausreichen. Also Lizenzanpassung der Datenbanken auf die aktuelle und überprüfte Lizenz-Datei nur, wenn auch das nicht geht.

Ob Sie dann die Anpassungs-Reparatur nur auf dem Einzelplatz machen, die Arbeit des 16.11. nach Korrektur der DB-Lizenz-Beziehung dort per Hausbesuchsexport extrahieren und in die Datenrücksicherung des 15.11. am Praxis-Server einfügen (dabei werden etliche Dinge nicht mit-übertragen: insbesondere iv-Vertrags-/DMP-Formular-Inhalte und auch Praxisgebühr-Buchungen) oder nach der Reparatur-Übung dies dann auf dem Server wiederholen, ist Strategie...

Wenn die Lizenzdatei korrekt ist, können Sie die Anpassung machen, ohne den Datenbestand zu gefährden. Aber wie gesagt: bei korrekter Lizenz und einwandfrei möglichem Zugriff darauf muss etwas an der PraxisDB korrumpiert sein

"Nach Strich und Faden testen" meint die über "Hauptmenü - Sonstiges - Wartung" angebotenen Überprüfungen.

Grüsse, Wahnfried
--> gestern abend Licht am Auto angelassen, daher heute früh nicht zur Medica...

[nmndoc]

Hallo zusammen,

ich komme wohl erst heute Abend oder morgen im Laufe des Tages dazu, o.g. Dinge zu testen. Trotzdem schon mal vielen Dank für die Tipps!

[nmndoc]

kurze Rückmeldung. Ich habe nun als ersten Test die Datensicherung vom Freitag Nachmittag/Abend rückgesichert, die erstellt wurde, unmittelbar bevor der Fehler auftrat (Überprüfung der Dasi war noch erfolgreich). Nun kommt der Lizenz-Fehler nicht mehr. Vorsorglich werde ich am Montag aber die Mitarbeiterinnen nochmals kontrollieren lassen, ob alles da + korrekt ist.

Bei der Gelegenheit ist mir nochmals aufgefallen, wie nervig diese Abfrage von diversen Kennwörtern in TM bei allen möglichen und unmöglichen Gelegenheiten ist. Oft braucht man doch gerade dann eins, wenn die Hotline nicht erreichbar ist. Man kann sich zwar theoretisch mal eins notiert haben und am Systemdatum rumspielen - daber das ändert am Grundproblem auch nichts.

[nmndoc]

Hallo,

nur der Vollständigkeit halber: Wir hatten großes Glück und die Rücksicherung der letzten Datensicherung war ausreichend + erfolgreich. Scheint fast so als sei die Datenbank direkt im Anschluß an die Sicherung korrupt geworden? Aber wohl eher Zufall...? (Sicherung ganz normal via TM, Station1 auf USB-Stick).

Gruß + danke für die nützlichen Hinweise.

[rfbdoc]

Neu in der aktuellen Version ist übrigens folgender Menüpunkt:
Sonstiges->Information->Lizenzdaten
Hier werden der Lizenzmodus (Bintab bzw. xml-Datei) und der Speicherort der Lizenzdatei angegeben

[benni]

Ich habe selbiges Problem bereits 2 x erlebt: vor einem Jahr und zuletzt vor ca. 6 Wochen, beides unter BINTAB.DAT Lizenz.
Es läuft immer nach dem gleichen Schema ab: Man macht eine Sicherungskopie, dabei geht etwas schief und sowohl die PraxisDB und auch eben diese Sicherung
ist Schrott. Beim letzten Mal hat es mich einen ganzen Tag an Dokumentation gekostet, weil abends zuvor die regelmäßige Sicherung vergessen wurde....
Ich habe nun auch eine XML.Lizenz und hatte gehofft, das Problem sei damit erledigt, ist wohl scheinbar nicht.
Bei mir läuft jetzt 2 x tgl ein automatischer Backup der PraxisDB direkt am Server, davon kann man etvl. etwas rekonstruieren.
Übrigens hat die vorgeschlagene "Anpassung der Lizenz" immer nur Müll ergeben... das war allenfalls mal zum gezielten BDT-Export der letzten Patienteneingaben auf einem Testrechner gut.
Weiterarbeiten würde ich mit so einer angepassen PraxisDB auf keinen Fall...
Was mich am meisten genervt hat, dass die Hotline mir überhaupt nicht helfen wollte: "Bitte wenden Sie sich an den Turbomedpartner vor Ort." Was kann den der TM Partner dafür, wenn die Datenbankspeicherroutinen die Datenbank abschießen.

[Lazarus]

Es läuft immer nach dem gleichen Schema ab: Man macht eine Sicherungskopie, dabei geht etwas schief und sowohl die PraxisDB und auch eben diese Sicherung
ist Schrott.

Wenn die Datenbank beim Lesen im Rahmen einer Sicherung zerstört wird, sieht das sehr nach einem Hardwareproblem aus. Zumindestens die Festplaate sollte ausgewechselt werden.
Wie oben erwähnt besteht auch die Möglichkeit, dass beim TM-Neustart nach der Sicherung der Bezug zum Server bzw. zur Lizenz verloren geht und die Datenbank auf Dr. Mustermann geändert wird. Wenn dabei abgebrochen wird, ist es mit der Datenbank vorbei. Am besten die Lizenz lokal suchen lassen.
Grüße
Lazarus

[nmndoc]

Hallo Lazarus,

ich habe das ganze RAID überprüfen lassen und er hat tatsächlich 1 inkonsistenten Block (oder so ähnelich) gefunden - wäre schon großes Pech - wenn da gerade die TM-DB lag und just in diesem Moment die Inkonsistenz auftrat - ich denke die war schon länger da und hat nur nicht gestört.
Ich versteh nicht ganz, weshalb

a) TM nach der Sicherung neu gestartet werden sollte/wird und
b) weshalb dort die Lizenz/DB konvertiert werden sollte? Soweit ich gesehen habe muss man da ein Tageskennwort eingeben, so dass dies ja nicht versehentlich passierden dürfte?
c) Lizenz am client lokal suchen lassen? (statt zuerst auf Server suchen). Wäre da dann nicht eher die Gefahr von falschen Lizenzen?

Evtl. können Sie Ihren Gedankengang genauer ausführen, so dass ich auch folgen kann

[Lazarus]

Wenn die korrekte Lizenz lokal gespeichert ist, muss TM diese nicht auf dem Server suchen. Nach der Sicherung startet TM alles nochmal neu, daher vermutete ich einen kurzfristigen Netzwerkfehler bei diesem Vorgang mit fehlerhafter (lokaler) Lizenz. Im Prinzip müsste es daher reichen, die entsprechenden Lizenzdaten lokal zu speichern. Um zu prüfen, ob alles korrekt ist, kann man nach einer Datenspiegelung in das lokale Verzeichnis den Rechner im Einzelplatzbetrieb starten. (Mit der Bitte, hinterher wieder auf Mehrplatzbetrieb umzustellen...)

[wahnfried]

...Ich habe nun auch eine XML.Lizenz und hatte gehofft, das Problem sei damit erledigt, ist wohl scheinbar nicht.
...
Übrigens hat die vorgeschlagene "Anpassung der Lizenz" immer nur Müll ergeben... das war allenfalls mal zum gezielten BDT-Export der letzten Patienteneingaben auf einem Testrechner gut.
Weiterarbeiten würde ich mit so einer angepassen PraxisDB auf keinen Fall...

Ob Sie eine BINTAB.DAT oder XML-Datei als Lizenz haben, hat mit den Dingen, die bei einer Datensicherung schief laufen können, sicherlich nichts zu tun.

Der Wechsel von einer BINTAB.DAT- auf eine XML-basierte Lizenz geschieht meist nur bei einem Praxisstrukturwechsel. Das Auswechseln der Lizenz geschieht auch durch die Servicepartner nicht anders als über den Menüpunkt "Neue Lizenz einspielen". Nur daß sich dann der Servicepartner darum kümmert, auch die Arzt- und Praxisdaten unter "Hauptmenü - Sonstiges - Praxisdaten/Privatabrechnungsdaten" zu korrigieren, wobei man sonst bei Eigenarbeit irgendwelche Punkte gerne vergisst.

Wenn Sie also einen Lizenzwechsel mitgemacht hatten, dann HABEN Sie ja bereits eine solche angepasste PraxisDB in Gebrauch. Ist also nicht gefährlich, wenn man weiß, dass die neue Lizenz wirklich nötig ist. Bei nicht veränderter Praxisstruktur ist dies aber NIE nötig. Wenn also solch ein Ansinnen ohne Grund kommt, auf jeden Fall abbrechen und erstmal die PraxisDB mehrfach kopieren, um dann die Fehlersuche mit einer dieser Kopien zu üben.

Was mich am meisten genervt hat, dass die Hotline mir überhaupt nicht helfen wollte: "Bitte wenden Sie sich an den Turbomedpartner vor Ort." Was kann den der TM Partner dafür, wenn die Datenbankspeicherroutinen die Datenbank abschießen.

Das kann ich gut verstehen, da die Hotline allenfalls Unterstützung zur Prüfung und ggfs automatisierten Korrekturen der Datenbanken geben kann. Alles Andere ist so variabel, daß ein Fachmann am Ort sinnvoll ist. Bei manchen Problemen, die einen Bezug zu TurboMed selbst haben, läßt sich TurboMed auch schon mal die PraxisDB schicken und schaut dann selbst nach. Das, was Sie geschildert haben, ist aber möglicherweise ein Hardware-Problem, wo man Bauteile testen und ggfs ersetzen muss. Das kann natürlich die Hotline nicht übernehmen. Sie könnte allerdings dies freundlich rüberbringen;-)

Grüsse, Wahnfried