Version 25.2.2

[Kasimir]

Hallo, fschmidt,

siehe hier:
viewtopic.php?p=69275#p69275

[fschmidt]

Vielen Dank! Wir haben dann so eingereicht!

Update kann ich nicht installieren, da wir das tmadmin Tool via Skriping für Backups verwenden

[Medizinmann]

Habe das aktuelle Update am Mittwoch erfolgreich installiert. Soweit keine Probleme.
Einzig nervt, dass nach jeder Öffnung des BMP (Medikationsplan) jedesmal auf "Speichern" gedrückt werden muss. Auch wenn nichts geändert wurde...

[RAMöller]

Ich habe nun die Version 25.2.2.6550 installiert.
Beim Neustart nach Installationvon TM (als admin) an einem Rechner will dieser wieder die Datenbank initialisieren für den FOS 14.0, obwohl alle anderen gestarteten Rechner bereits auf die Datenbank problemlos zugreifen können.
Sollte bei diesem Initialisierungsversuch etwas anderes auf die Datenbank zugreifen, so ist diese hinüber.
Ich habe den Rechner ausgeschaltet und TM im Normalmodus neu gestartet, dabei erfolgte kein weitere Initialisierungsversuch, ich hoffe es bleibt auch so...
Momentan halte ich die Version 6550 unter diesen Bedingungen für unbedienbar

[torsten2]

Vielen Dank! Wir haben dann so eingereicht!

Update kann ich nicht installieren, da wir das tmadmin Tool via Skriping für Backups verwenden

Ich nutze das auch so. Funktioniert das tmadmin Tool in Version 14 gar nicht mehr? Sollte man alternativ den FOS dann ganz beenden und kopieren, wird bei mir automatisch über Nacht gemacht?! Hat jemand nähere Infos?

[RAMöller]

Die Datensicherung mit einem Script via tmadmin funktioniert. Das ist nicht das Problem.
Wenn tmadmin gestartet wird, werden Datenbankzugriffe zwischengespeichert und am Ende übertragen.

Das ursprüngliche Problem trat mit der Turbomed eigenen Datensicherung beim Beenden auf. Während dieser Sicherung wollte ein versehentlich gestarter Rechner gleichzeitig die Datenbank für FOS 14.0 initialisieren und alles war hinüber.

Jetzt soll dieser Fehler behoben sein, ich bezweifele das, da weiterhin Rechner gelegentlich versuchen, die Datenbank zu initialisieren, obwohl der Zugriff eigentlich während der bordeigenen Sicherung gar nicht möglich sein sollte.

Damit ist dieses Programm für normale Anwender ungeeignet bzw. unbedienbar geworden

[torsten2]

Da bin ich beruhigt. Vielen Dank für die schnelle Antwort am Wochenende!!

[SFeu]

Eine mit tmwinadmin "gesperrte" Datenbank führte bei uns mehrfach zu einer inkonsistenten,
fehlerhaften Sicherung, TM startete dann auf einem rückgesicherten System nicht mehr.
Ich traue dieser Datensicherungs-Variante seitdem nicht mehr.

[RAMöller]

Eine mit tmwinadmin "gesperrte" Datenbank führte bei uns mehrfach zu einer inkonsistenten,
fehlerhaften Sicherung, TM startete dann auf einem rückgesicherten System nicht mehr.
Ich traue dieser Datensicherungs-Variante seitdem nicht mehr.

Ok, bordeigenesTM-Backup ist aktuell etwas riskant, TMadmin lief eigentlich bisher immer recht gut so nebenbei, tmwinadmin kannte ich noch nicht, Spiegelung wäre noch eine weitere Option, sofern im Anschluss überprüft wird.
Wie soll denn nun die optimale Sicherung der Datenbank vonstatten gehen?

[torsten2]

Also bei mir sieht der Teil im Script so aus:

C:\TurboMed\Programm\Tmadmin /beginbackup /server=*********
robocopy C:\TurboMed\PraxisDB\ %destin% /MIR /W:1 /R:0
C:\TurboMed\Programm\Tmadmin /endbackup /server=*********

Das Stück Script ist, glaube ich, sogar von CGM. Wenn das noch so geht, würde ich es belassen. Ich mache das seit 10 Jahren mit Scripten. Wenn die einmal so hingetrimmt sind, daß sie funktionieren, läuft das alles sehr zuverlässig. Es wird über den Windows Cron automatisch in der zweiten Nachthälfte ausgelöst, da ist sowieso keiner am Arbeiten.

[RAMöller]

Also bei mir sieht der Teil im Script so aus:

C:\TurboMed\Programm\Tmadmin /beginbackup /server=*********
robocopy C:\TurboMed\PraxisDB\ %destin% /MIR /W:1 /R:0
C:\TurboMed\Programm\Tmadmin /endbackup /server=*********

Das Stück Script ist, glaube ich, sogar von CGM. Wenn das noch so geht, würde ich es belassen. Ich mache das seit 10 Jahren mit Scripten. Wenn die einmal so hingetrimmt sind, daß sie funktionieren, läuft das alles sehr zuverlässig. Es wird über den Windows Cron automatisch in der zweiten Nachthälfte ausgelöst, da ist sowieso keiner am Arbeiten.

So ist der Art machen wir es auch, inkl. IV-Verwaltung, Dokumente etc.
Das Backup von TM nutze ich zusätzlich für einen externen Speicher zu Mitnehmen. Im Grunde genommen ist das alles keine Raketenwissenschaft. (und hat funktioniert nach dem FOS14/12 Crash)
Irgendetwas stimmt seit der Umstellung auf FOS14.0 nicht mehr, die TM-seitigen Routinen scheinen den FOS nicht richtig zu bedienen, wobei diese "neusprechartige" Namensvergabe FOS 14 = FOS 12 sehr verdächtig ist.

[ralph.mertens]

Bzgl. der Namensgebung des FOS-Dienstes habe ich das Script aus dem Artikel FOS als Dienst von rfbdoc übernommen und nur den Dienstnamen geändert.

Code: Alles auswählen

@echo off
::Auslesen der Windowsversion 32bit oder 64bit
reg Query "HKLM\Hardware\Description\System\CentralProcessor\0" | find /i "x86" > NUL && set OS=32BIT || set OS=64BIT
if %OS%==32BIT goto :Win32
if %OS%==64BIT goto :Win64

::Auslesen des TurboMed Installationspfades aus der Registry
:Win32
@for /f "tokens=2*" %%i in ('reg query "HKEY_LOCAL_MACHINE\SOFTWARE\TurboMed EDV GmbH\TURBOMED\Current" /v Path') do @Set "x=%%~j"
echo Win32
echo TurboMed Installation: %x%
set TmPfad= %x:~0,2%
echo TmBasisverzeichnis:%TmPfad%
echo%TmPfad% als Variable TmPfad gesetzt
echo Die Variable wurden aus der Registry ausgelesen
goto :Weiter

:Win64
@for /f "tokens=2*" %%i in ('reg query "HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\TurboMed EDV GmbH\TURBOMED\Current" /v Path') do @Set "x=%%~j"
echo Win64
echo TurboMed Installation: %x%
set TmPfad= %x:~0,2%
echo TmBasisverzeichnis:%TmPfad%
echo Die Variable wurden aus der Registry ausgelesen
echo TmPfad=%TmPfad% gesetzt
goto :Weiter

:Weiter
Pause

cls
net stop "FastObjects Server (x64) 12.0"
net stop "FastObjects Server 12.0"
taskkill /f /im FastObjectsServer.exe
taskkill /f /im FastObjectsServer64.exe
sc delete "FastObjects Server (x64) 12.0"
sc delete "FastObjects Server 12.0"
Echo ###################################################################################
Echo Hinweis: Systembedingt wurden Befehle nicht erfolgreich ausgefuehrt. Kein Fehler ! Keine Panik !
Echo ###################################################################################
Echo Weiter mit beliebiger Taste. Im folgenden Schritt wird der FOS gestartet
Pause>nul
cls
del "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\TurboMed Datenbank Server*.lnk"
sc create "FastObjects Server (x64) 14.0" start= auto binpath= "%x:~0,2%\TurboMed\Programm\FastObjects64\FastObjectsServer64.exe -config %x:~0,2%\TurboMed\Programm\ptserver.cfg"
sc failure "FastObjects Server (x64) 14.0" actions= RESTART/60000/RESTART/60000/RESTART/60000 reset= 86400
cls
net start "FastObjects Server (x64) 14.0"
pause

Den Code als <xxx>.BAT oder <xxx>.CMD speichern und als Administrator ausführen.

[Schicki]

Ich habe wieder mal Stunden am Sonntag in der Praxis wegen eines Updates verbracht...
Update zu 25.2.2
Nach der Installation an den anderen Arbeitsplätzen:DB Kernel Error - SSL client connention could not be instantited. (-2636)
nun habe ich die Firewall abgeschaltet und habe zumindest für Montag eine funktionierende Version.

Will es aber so nicht lassen. Was kann ich tun?
Ich habe allerdings nach der Datenbankaktualisierung eine Frage ggf. falsch beantwortet, Wer weiß, was da gefragt wurde? Ich habe den linken Button gedrückt, da ich dachte , das wäre schon die Frage bezüglich der Medikamente.

MfG
Schicki

[SFeu]

Schnelle Abhilfe: auf den Clients in den Grundeinstellungen die verschlüsselte Verbindung zum Server ausschalten

(Anm.: Danke an User pmortara: "Für den neuen FOS muss wohl zusätzlich noch der Port 6061 in der Firewall durchgelassen werden.")

[lieske-elektronik]

Hallo,
ich habe heute das Update installiert. Auf dem Server kam die Meldung mit dem Update von FOS12 auf FOS 14, welche ich bestätigte und das Update lief auch durch. Von den Dateinamen her hat das Update geklappt und es ist V14. Allerdings habe ich ein Problem an einem Arbeitsplatz, dort kommt die Meldung beim Start von TM ständig. Man kann sie ja nur bestätigen, dann kommt die Fehlermeldung, dass die Dateien auf dem Server gesperrt seien und nicht aktualisiert werden können. Danach beendet sich TM. TM ist auf diesem Platz aktuell nicht lauffähig. Ich habe das Update erneut durchgeführt, es gab keine Änderung. Hat jemand eine Idee, woran das liegen könnte? Vielen Dank.

[FortiSecond]

Hallo,
ich habe heute das Update installiert. Auf dem Server kam die Meldung mit dem Update von FOS12 auf FOS 14, welche ich bestätigte und das Update lief auch durch. Von den Dateinamen her hat das Update geklappt und es ist V14. Allerdings habe ich ein Problem an einem Arbeitsplatz, dort kommt die Meldung beim Start von TM ständig. Man kann sie ja nur bestätigen, dann kommt die Fehlermeldung, dass die Dateien auf dem Server gesperrt seien und nicht aktualisiert werden können. Danach beendet sich TM. TM ist auf diesem Platz aktuell nicht lauffähig. Ich habe das Update erneut durchgeführt, es gab keine Änderung. Hat jemand eine Idee, woran das liegen könnte? Vielen Dank.

Ich würde zuerst, sicherheitshalber, die global.ini und die local.ini im Programm-Ordner sichern, dann mit denen von einem funktionierenden Platz ersetzen.
So als erster Ansatz. Wenn das schon reicht, ggf. die Unterschiede ansehen - falls die Station besondere Einstellungen haben sollte.

[lieske-elektronik]

Danke, das hat leider nichts geholfen. Die Ini-Dateien waren gleich. Ich habe das Problem aber temporär gelöst, indem ich in den Grundeinstellungen die Option "Automatische Kontrolle für den Datenkonvertierungslauf" deaktiviert habe. Nun startet TM.
Ich weiß nicht, ob die Option irgendwie wichtig ist, denn ich für das Update ja immer zuerst auf dem Server aus und konvertiere auch dort alle Daten.

[Andreas]

Hallo,
ich habe heute das Update installiert. Auf dem Server kam die Meldung mit dem Update von FOS12 auf FOS 14, welche ich bestätigte und das Update lief auch durch. Von den Dateinamen her hat das Update geklappt und es ist V14. Allerdings habe ich ein Problem an einem Arbeitsplatz, dort kommt die Meldung beim Start von TM ständig. Man kann sie ja nur bestätigen, dann kommt die Fehlermeldung, dass die Dateien auf dem Server gesperrt seien und nicht aktualisiert werden können. Danach beendet sich TM. TM ist auf diesem Platz aktuell nicht lauffähig. Ich habe das Update erneut durchgeführt, es gab keine Änderung. Hat jemand eine Idee, woran das liegen könnte? Vielen Dank.

Hallo,
das hatte ich auch, ich habe einfach an allen Arbeitsplätzen TM beendet und nur auf dem Rechner mit der Meldung TM gestartet und dann lief eine Aktualisierung durch, danach funktionierte der Arbeitsplatz ganz normal.

[fschmidt]

so, nun überlegen ich auch, das Update einzuspielen.
Wir nutzen einen vergleichbaren Ansatz zu

C:\TurboMed\Programm\Tmadmin /beginbackup /server=*********
robocopy C:\TurboMed\PraxisDB\ %destin% /MIR /W:1 /R:0
C:\TurboMed\Programm\Tmadmin /endbackup /server=*********

Jedoch mit regelmäßigen Sicherungen auf diese Art im laufenden Betrieb. Das hat bei unserem letzten Ausfall vor 5 Jahren geholfen, so dass wir nur Daten einer halben Stunde erneut erfassen mussten. Daher möchten wir das auch nicht ändern.

Beim Test auf unserem Testsystem mit Start des Backups, bearbeiten der Daten (Karteikarte und Kalender), Ende des Backups klappte alles.

Gibt es weitere Erfahrungswerte, ob es so mit dem Backup im laufenden Betrieb funktioniert?

Vielen Dank für jede Rückmeldung!

Also bei mir sieht der Teil im Script so aus:

C:\TurboMed\Programm\Tmadmin /beginbackup /server=*********
robocopy C:\TurboMed\PraxisDB\ %destin% /MIR /W:1 /R:0
C:\TurboMed\Programm\Tmadmin /endbackup /server=*********

Das Stück Script ist, glaube ich, sogar von CGM. Wenn das noch so geht, würde ich es belassen. Ich mache das seit 10 Jahren mit Scripten. Wenn die einmal so hingetrimmt sind, daß sie funktionieren, läuft das alles sehr zuverlässig. Es wird über den Windows Cron automatisch in der zweiten Nachthälfte ausgelöst, da ist sowieso keiner am Arbeiten.

So ist der Art machen wir es auch, inkl. IV-Verwaltung, Dokumente etc.
Das Backup von TM nutze ich zusätzlich für einen externen Speicher zu Mitnehmen. Im Grunde genommen ist das alles keine Raketenwissenschaft. (und hat funktioniert nach dem FOS14/12 Crash)
Irgendetwas stimmt seit der Umstellung auf FOS14.0 nicht mehr, die TM-seitigen Routinen scheinen den FOS nicht richtig zu bedienen, wobei diese "neusprechartige" Namensvergabe FOS 14 = FOS 12 sehr verdächtig ist.

[DocET]

Beziehen sich Ihre Berichte auf die Version 25.2.2.6550, die auf der Turbomed Seite mit Datum vom 16.04.2025 zum Download bereitsteht? Oder gab es eine Vorgängerversion?