VonDoczuDoc.de

Fehlermeldung: Praxidict kann nicht gefunden werden
Diese Fehlermeldung erscheint u.a. wenn die Datei Ptserver.cfg nicht gefunden wird
(oder der FOS nicht läuft)

FastObjectsServer64.exe auf dem Server suchen->Eigenschaften->Einstellungen für alle Benutzer ändern->Ausführen als Administrator aktivieren und speichern. Zugleich auch hier noch einen Blick auf Sicherheitseinstellungen: Volle Zugrifffsrechte

Auch mal die Sicherheitseinstellungen der ptserver.cfg überprüfen. Volle Zugriffsrechte

Was passiert wenn sie in der Windows- Diensteverwaltung den FOS Beenden und Neustarten ?

Die Meldung Zeitüberschreitung könnte auch auf ein Netzwerkproblem hinweisen, vermutlich ist es aber der FOS

Ptserver.cfg hat Vollzugriff.

Der FOS läuft nicht, trotzdem er als Dienst eingetragen ist. In der Diensteverwaltung erscheint die Meldung, daß er als Dienst gestartet, dann aber angehalten wurde, siehe Anhang.
Das ist mir ein Rätsel.
Vor dem Update ging noch alles...

Ich habe auch 2x FOS: einmal unter TM/Programm, das ist die 32 bit-Variante, und dann im Ordner TM/Prog./Fastobj.S.64 die 64 bit Variante. Das ist aber schon seit Jahren so. Selbst, wenn ich die 32 bit-Variante als Dienst einrichte, erscheint in der Diensteverwaltung der 64er. Daran wird es wohl nicht liegen.

Alles ist normal so wie sie es beschrieben haben. (FOS32 und 64bit beide vorhanden)
Haben Sie Ausführen als Administrator in den Eigenschaften des FOS64bit für alle Benutzer eingestellt ???
Ich hatte nach dem Update eine neue ptserver.cfg mit aktuellem Tagesdatum im Ordner TurboMed\Programm, diese habe ich in den Ordner Fastobjects64 verschoben. Dann die Einstellungen in den Eigenschaften des Fastobjectsserver64 für alle Benutzer angepasst. Erst danach Neustart des FOS mit rechter Maustaste Ausführen als Administrator, danach Configure als Service in den Optionen eingestellt mit anschliessendem Neustart ohne das FOS Fenster zu schliessen.
Dann muss der FOS laufen- hoffentlich

Einrichten des FOS (nächträglich eingestellt) Screenshots zu Einstellungen in den Eigenschaften der Datei Fastobjectsserver64.exe

Auch ich habe gewagt die zweite Version zu installieren. Das update auf dem Server und den Clients ging reibungslos und max binnen 30 Minuten: auf jedem Client extra installiert, kein Netsetup. Den FOS von Hand gestartet. Alle Clients starten auch und haben Zugriff UF DIE Datenbank. Dale UV Einzelversand in der Berichtsübersicht funktioniert. Funktionalität nicht verbessert. Stapelversand führte im ersten Anlauf zum Absturz von TM. Zweiter Anlauf mit ca 50 Berichten etc. läuft gerade. Statt die Ti zu bewerben sollte CGM mal zeigen, dass wenigstens dieses funktioniert. Werde wohl nächste Woche mal wieder beim DGUV vorsprechen und um Unterstützung bitten. Irgendwann muss ja mal gut sein! In diesem Sinne einen guten Übergang!

That´s it,
rfbdoc ist wieder mal Spitze! Es sind die kleinen Feinheiten.
Die Arabeske mit den voreingestellten Administrator-Eigenschaften ist nun wirklich schon höhere IT-Logik!

Aber das hat funktioniert, nachdem der Neustart erfolgte.
Herzlichen Dank! Silvester ist gerettet.
Und guten Rutsch in ein hoffentlich Patch-,Nach- und Sonder-Updatearmes 2018. (Wer´s glaubt...)

Hallo,
weiß jemand, welche Version auf der DVD ist?

Gruß Nobbie

@ eusebius
Freut mich dass alles wieder läuft, manchmal ist`s halt vertrackt.

@nobbie
Die Update DVD beinhaltet 18.1.1.3526, entsprechend der Downloadversion vom 21.12.2017

Abgesehen von der Fastobjects- Problematik läuft diese Version sonst offensichtlich ohne Probleme.


Allen im Forum ein schönes Silvesterfest und ein Gutes Jahr 2018 !

Bei uns ist das Update seit Längerem erstmalig auf allen Rechnern glatt durchgelaufen - bis auf ein paar kleine Nickeligkeiten die ich nicht verstehe und die vielleicht auch nicht entscheidend sind:

Problemloses Serverupdate, aber im netsetup - Ordner sind wieder mal keine Installationsdateien. Also Installationsdateien auf dem Server abgelegt, und von dort die Clients upgedatet.

Müssen auf den Clients die updates eigentlich mit einem Administratorzugang gefahren werden? Auf allen Rechnern einschl. Server haben wir Win 10 Pro. Einige clients haben sich beim Anmelden mit Administratorrechten beschwert, es sei die höchstmögliche Zahl an client-Anmeldung am Server bereits erreicht. Das kann nicht ganz stimmen - die (gemappten) Serverlaufwerke wurden nämlich angezeigt, nur die setup.exe startete nicht. Dann habe ich die Clients mit normalen Rechten angemeldet und die setup.exe problemlos mit Adminstratorrechten (rechte Maustaste....) ausführen können.

Und muss Turbomed auf den clients auch ein mal mit Admin-Rechten gestartet werden, oder genügt es das auf dem Server zu tun?

Ich wünsche allen Kollegen ein erfolgreiches 2018!

Wir machen die Updates immer mit Administratorrechten und starten TM einmal als Administrator auf allen PC´s.

XRAY hat geschrieben:Wir würden uns gerne das Update 17.4 ersparen und direkt von 17.3 auf 18.1 updaten.

Laut Installationsanleitung "muss mindestens die CGM TURBOMED Version 17.4.1. installiert sein".
Gibt es neben Elkrib (http://vondoczudoc.de/viewtopic.php?f=11&t=6541#p40685) weitere Kollegen, die ggf. diesen Schritt erfolgreich gegangen sind?

Vielen Dank für Ihre Erfahrungsberichte, xray

Hallo habe das Gleiche schon als Einzelplatz auf dem Testrechner von 17.3.1 auf 18.1.1. gemacht. Meldung ignoriert.
Es läuft incl. der Abrechnung alles top !

Einspielen der Version problemlos, beim Versenden der DA Berichte active Skript error, d.h. Versand per dale uv nicht möglich, Hotline seit 10 Min Warteschleife.... D- Ärzte noch abwarten....alles andere scheint zu laufen.... oder hat´s schon jemand ohne Fehler installiert ???

Betroffen sind auch die Zwischenberichte, nach Auskunft der Hotline arbeitet man an einer Lösung....cgm telematikinfrastruktur lässt grüßen...
Ich hoffe immer noch dass dieser Kelch an uns vorüber geht...

gibt seit heute einen Patch zur 18.1.1 der u.a. DALE-Fehler behebt.

Habe die Version 18.1.1.3526 installiert, lief relativ problemlos, einmal Fehler bei einem Client dass ipc3(??).. noch läuft, Installation unterbrochen, Abhilfe schaffte Neustart des Servers( ich denke beim ersten Start des TM am Server und Beenden des TM am Server lief Ifap noch ), dann lief die Installation problemlos.
Netsetup gibt es weiterhin nicht. FastObjetserver muss manuell gestartet werden.
Laborblatt läuft gefühlt schneller, ein kleiner Lichtblick .

Gruss

Habe die Version 18.1.1.3526 installiert einschließlich des Patch für Dale-UV, lief problemlos am Server (Win2012) und allen Stationen (Win7 - 64). Ob das Patch was bringt, wird sich nächste Woche zeigen. Seltsamerweise lief bei uns Dale-UV in den letzten 2 Wochen fehlerfrei!
Gruß Nobbie

Habe die Onlineversion 18.1.1 3534 installiert (Download am 6.1). Der Patch ließ sich nicht mehr installieren, ich gehe davon aus, weil er schon eingebaut wurde. Oder auch nicht, man wird sehen.
Nach der Reanimation des FOS lief es dann wieder inkl. Fehlermeldung "barrierefreie Praxis". Reine Zeitverschwendung, also für Nicht-Fachinformatiker.
Warum hat sich der Ordner NetSetup geleert...was soll das? Ich fand den nicht do übel, wenn man mal ein paar alte Programmfragmente gesucht hat, z.B. für den TMKarteidrucker

Auch wenn das von CGM/TM nich kommuniziert wird, denke ich, dass die Netsetup Automatik "ausgebaut" wurde.
Der nach Update/Installationsanleitung erforderliche Aufruf der setup.exe über Kontextmenu "Ausführen als Administrator" ist offensichtlich in den programminternen Aufruf des Updates nicht zu implementieren.

rfbdoc hat geschrieben:Auch wenn das von CGM/TM nich kommuniziert wird, denke ich, dass die Netsetup Automatik "ausgebaut" wurde.
...

Hallo,
kann ich nicht erkennen, bei uns funktioniert(e) das Befüllen von Netsetup und das automatische Update der Clients beim ersten Start nach Update des Servers seit Umstellung von TM-DOS auf TM-WIN 2008 bis einschließlich 18.1.1 immer zuverlässig.
Man sollte lediglich das Update an den Clients erst starten, wenn das Update am Server weitgehend durch ist, da zumindest bisher beim Serverupdate erst der Inhalt der "1.CD" (obwohl ja schon lange von 2CD's auf 1 DVD umgestellt wurde, lief es ja immer noch als 2CD-Version) in Netsetup kopiert wurde, dann ein Teil des Updates durchlief, dann der Inhalt der "2.CD") in Netsetup kopiert wurde, und dann schließlich der Rest des Serverupdates erfolgte.
Bei Start an den Clients kurz nach Beginn am Server ist es mir anfänglich einmal passiert, daß die Updateroutine an den Clients schneller als am Server ablief (hier entfällt ja der Kopiervorgang von DVD in Netsetup) und daher nach etwa der Hälfte wegen noch nicht vorhandener Dateien fehlerhaft abbrach.

Vor diesem Update hatte ich noch 17.1.2.
Da ich mir nicht sicher war, ob es jetzt beim Überspringen von Updates nicht doch ernstliche Probleme gibt, da ja als Voraussetzung für 18.1.1 mindestens 17.4.1 angegeben war, habe ich zuerst die letzte offizielle "Installationsversion" 17.3.2, dann 17.4.1 und schließlich 18.1.1 am Server installiert und jeweils dazwischen den Server neugestartet.
Es wurde jedesmal Netsetup korrekt befüllt, bei 17.3.2 und 17.4.1 auch Fastobjectsserver64 korrekt als Dienst gestartet.
Lediglich nach Update 18.1.1 wurde kurioserweise eine Verknüpfung "TurboMed Datenbank Server (x64)" zu Fastobjectsserver64 ins Autostartverzeichnis gelegt und auch gleich gestartet. Der Dienst war noch vorhanden, bei Klick auf Starten kam die Meldung "wurde gestartet und wieder angehalten" oder so ähnlich, möglicherweise, weil ja der Fastobjectsserver schon als Programm gestartet worden war.
Habe dann die Verknüpfung aus dem Autostartordner gelöscht, nach Neustart gings dann wieder als Dienst.
Dabei ist mir allerdings aufgefallen, daß man den Pfad der ptserver.cfg geändert hat:
vorher:
E:\Turbomed\Programm\FastObjects64\FastObjectsServer64.exe -config "e:\Turbomed\Programm\FastObjects64\ptserver.cfg"
jetzt (auch bei der 64Bit-Version):
E:\Turbomed\Programm\FastObjects64\FastObjectsServer64.exe -config "e:\Turbomed\Programm\ptserver.cfg"

Das war wohl auch überfällig, da beim Update \turbomed\Programm\ptserver.cfg schon immer "gewartet" wurde, hatte nach jedem Update zumindestens ein aktuelles Datum, \Turbomed\Programm\FastObjects64\ptserver.cfg hatte bei mir dagegen ein Datum vom März 2015

Die Clients habe ich dann erst nachdem am Server alles fertig war gestartet, es kam wie üblich die Meldung, daß eine neue TM-Version in Netsetup liegt, das Update lief hier dann direkt von 17.1.2 auf 18.1.1.
Natürlich wurde bemängelt, daß die Voraussetzung 17.4.1 nicht erfüllt ist und dabei neben "Abbrechen" ein "Vollupdate" angeboten.
Letzteres lief problemlos durch, einen Unterschied zwischen "Vollupdate" und den bisherigen Updates habe ich nicht bemerkt.

Aufgefallen sind mir ansonsten noch 2 Dinge:
1. Wie nach jedem Update sind in den CGM-Assist Einstellungen wieder einige Häkchen gesetzt. Eins davon: "Hinweis VERA ® TopVersorgt" unter HZV-Assistent kommt nach dem deaktivieren hartnäckig immer wieder.

2. Sicherheitshalber lasse ich nach dem Update immer im Ifap unter Wartung eine Registrierungs- und Dateiprüfung laufen:
Bei der Dateiprüfung wird diesmal an allen Stationen eine fehlende Datei bemängelt: ifapDB\Praxiscenter3\ipcneu.exe: hab sicherheitshalber das ifap-Setup nochmal laufen lassen, diese Datei scheints definitiv nicht zu geben, ist wohl ein Fehler im Wartungsprogramm (hab mal versuchsweise ipc.exe in ipcneu.exe umbenannt, danach läßt sich Ifap zwar nur noch händisch via ipcneu.exe starten, TM läuft ohne ifap, aber die Datei- und Registrierungsprüfung laufen fehlerfrei durch ).

Gruß
FranzKonrad

Danke für die ausführliche Beschreibung !

Das “Ausbauen” der Netsetup-Routine war auch nur Spekulation. Allerdings hätte man damit erwzingen können, auf jedem Client das Update über das Kontextmenü Ausführen als Administrator anzustoßen.

Die nach dem Update aktualiserte ptserver.cf im Verzeichnis \TurboMed\Programm war mir auch schon aufgefallen. Ich habe sie dann manuell das das Verzeichnis TurboMed\Programm\FastObjects64 kopiert und den FOS neu gestartet.

Ihre ausführlicher Bericht über das weitehend fehlerfrei gelaufene Update in ihrer Konfiguration hat mich veranlasst in der Registry die Einträge für Imagepath bzw. Path in den Schlüsseln

Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\FastObjects Server (x64) 11.0

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FastObjects Server (x64) 11.0

Computer\HKEY_LOCAL_MACHINE\SYSTEM\Setup\FirstBoot\Services\FastObjects Server (x64) 11.0

manuell entsprechend ändern. Ich habe es hier jetzt mal so abgeändert und bin gespannt, ob beim nächsten Update der FOS nicht mehr händisch neu gestartet werden muss.