Update 18.1.1
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.
-
- PowerUser
- Beiträge: 2924
- Registriert: Sonntag 30. April 2006, 19:31
- 17
- Hat sich bedankt: 29 times
- Bedankt: 51 times
Re: Update 18.1.1
Ich habe einfach die Registry durchsucht nach "ptserver.cfg"
dabei gab es bei den o.a. 3 Schlüsseln entsprechende Einträge.
Auch nach dem 18.1.1 Update erfolgte jeweils der Verweis auf \TurboMed\Programm\Fastobjects64\ptserver.cfg
Die habe ich jetzt einfach entsprechend geändert. Danach sah man den auch in der Diensteverwaltung den Verweis auf die geänderte ptserver.cfg
@Kasimir: Vielleicht mal unter Eigenschaften die Sicherheitseinstellungen der Ordner \TurboMed\Programm\Fastobjects64\ und \TurboMed\Programm\ einsehen. Hat der User volle Zugriffsrechte ?
dabei gab es bei den o.a. 3 Schlüsseln entsprechende Einträge.
Auch nach dem 18.1.1 Update erfolgte jeweils der Verweis auf \TurboMed\Programm\Fastobjects64\ptserver.cfg
Die habe ich jetzt einfach entsprechend geändert. Danach sah man den auch in der Diensteverwaltung den Verweis auf die geänderte ptserver.cfg
@Kasimir: Vielleicht mal unter Eigenschaften die Sicherheitseinstellungen der Ordner \TurboMed\Programm\Fastobjects64\ und \TurboMed\Programm\ einsehen. Hat der User volle Zugriffsrechte ?
R.F.B.
-
- Beiträge: 432
- Registriert: Donnerstag 28. Juni 2012, 11:43
- 11
Re: Update 18.1.1
Ich habe es bei mir so, dass die Pfade in de Registry korrekt sind.
Installiert man aber ein TM Update, steht gar nichts mehr in der Registry zum FOS. Erst wenn ich den FOS per Hand starte und als Dienst einrichte, ist wieder ein (auch korrekter) Registry Eintrag vorhanden.
Aber wie gesagt, wenn nach einem Update der FOS nicht automatisch startet, ist die Registry auch leer. Das Update hat den Registry Eintrag offenbar entfernt.
Mittlerweile ist das ja Routine mit dem manuellem FOS-als-Dienst-hinzufügen nach einem Update, aber nervig ist das trotzdem schon.
Installiert man aber ein TM Update, steht gar nichts mehr in der Registry zum FOS. Erst wenn ich den FOS per Hand starte und als Dienst einrichte, ist wieder ein (auch korrekter) Registry Eintrag vorhanden.
Aber wie gesagt, wenn nach einem Update der FOS nicht automatisch startet, ist die Registry auch leer. Das Update hat den Registry Eintrag offenbar entfernt.
Mittlerweile ist das ja Routine mit dem manuellem FOS-als-Dienst-hinzufügen nach einem Update, aber nervig ist das trotzdem schon.
-
- Beiträge: 516
- Registriert: Dienstag 7. Oktober 2008, 13:56
- 15
- Wohnort: 91463 Dietersheim
Re: Update 18.1.1
Hallo,Henrik313 hat geschrieben:... Installiert man aber ein TM Update, steht gar nichts mehr in der Registry zum FOS. Erst wenn ich den FOS per Hand starte und als Dienst einrichte, ist wieder ein (auch korrekter) Registry Eintrag vorhanden. ...
das ist bei mir definitiv nicht so, auc nach den Updates läuft der Dienst, lediglich hat sich nach dem letzten Update die Pfadangabe für die ptserver.cfg geändert.
Ist bei Ihnen die Setup.cfg im Turbomed Verzeichnis korrekt (... "Stationtyp=Server" ...)?
Haben Sie schon einmal die Setup.log im Verzeichnis Turbomed\Support durchgesehen?
Hier steht ganz am Anfang Infos, auch bzgl. Mehrplatzsystem und Servername:
-------------------- TURBOMED Setup gestartet --------------------
Produktversion: 18.1.1
Installversion: 18.1.1.3526
Datum (MM-TT-JJJJ): 1-1-2018
Uhrzeit (SS:MM:ss): 19:36:56
Betriebssystem: OS Windows 7/Server 2008R2 (64 Bit)
TSClient: Nein
Zielverzeichnis Programm: e:\turbomed
Zielverzeichnis Registry: e:\turbomed
Quellverzeichnis: T:\TM-18-1-1\CGM_TURBOMED_Version_18.1.1.3526\
Setup Supportverzeichnis: C:\ProgramData\Temp\server-1\administrator_tmp\{D9FC92C6-6EB8-46DA-B70C-9E9E22AC6D05}
Es ist die TURBOMED Version 17.4.1 Build: 3458 installiert
Aktualisieren gewählt
Entwicklungsumgebung: 8
MSI Setup
MEHRPLATZBETRIEB: ja
SERVERNAME: localhost
...
dann etwas später:
...
----------------------------------------
Abschnitt: HandleRunningFOS
Datenbankserver behandeln
FOS: e:\turbomed\Programm\FastObjectsServer.exe
FOS64: e:\turbomed\Programm\FastObjects64\FastObjectsServer64.exe
Prüfen, ob der Datenbankserver läuft
Der Datenbankserver läuft auf dieser Station
Datenbankserver beenden
----------------------------------------
...
fast am Ende dann noch ein Abschnitt zum Fastobjectsserver, zur Erstellung der neuen Setup.cfg u. Registrierung von Turbomed
----------------------------------------
Abschnitt: AfterAll
Verschieben der 7z-Dateien
Datenbankserver starten net start "FastObjects Server (x64) 11.0"
Datenbankserver starten E:\turbomed\Programm\FastObjects64\FastObjectsServer64.exe
Die letzte Zeile war diesmal bei mir neu, Setup hat offenbar nicht nur den Dienst mit net start ... gestartet, sondern gleichzeitig auch den Fastobjectsserver als Programm, warum auch immer.
Prüfen, ob der Datenbankserver läuft
----------------------------------------
Abschnitt: WriteSetupCfg
----------------------------------------
Abschnitt: LaunchTurboMed
Der Hinweis wurde zur Kenntnis genommen.
Start der Turbomed-Registrierung : 1-1-2018 19:52:07
Ende der Turbomed-Registrierung : 1-1-2018 19:52:58
----------------------------------------
Abschnitt: weitere Informationen
Stationstyp : Server
Dateiversion: 18.1.1.3526
----------------------------------------
TURBOMED Setup beendet
Datum (MM-TT-JJJJ): 1-1-2018
Aber wie gesagt, auch nach den Updates habe ich immer den FOS-Dienst und auch ein gefülltes Netsetup-Verzeichnis.
Gruß
FranzKonrad
-
- PowerUser
- Beiträge: 1618
- Registriert: Mittwoch 11. Mai 2005, 20:23
- 18
- Wohnort: Land Brandenburg
- Hat sich bedankt: 3 times
- Bedankt: 25 times
Re: Update 18.1.1
Hallo.
Um nochmals auf den FastObjectsServer 64 bit zurückzukommen:
Bei mir steht in dessen "Eigenschaften" (unter Verwaltung/Dienste):
C:\TurboMed\Programm\FastObjects64\FastObjectsServer64.exe -config "ptserver.cfg"
Also es steht hinter "config" kein Laufwerksbuchstabe. Beim 32-bit-FOS steht jedoch einer.
Vielleicht ist das die Ursache, dass der 64erFOS die Dictionary nicht finden kann. Aber: Wo und wie kann ich das ändern?
Um nochmals auf den FastObjectsServer 64 bit zurückzukommen:
Bei mir steht in dessen "Eigenschaften" (unter Verwaltung/Dienste):
C:\TurboMed\Programm\FastObjects64\FastObjectsServer64.exe -config "ptserver.cfg"
Also es steht hinter "config" kein Laufwerksbuchstabe. Beim 32-bit-FOS steht jedoch einer.
Vielleicht ist das die Ursache, dass der 64erFOS die Dictionary nicht finden kann. Aber: Wo und wie kann ich das ändern?
Viele Grüße
Kasimir
Kasimir
-
- Beiträge: 516
- Registriert: Dienstag 7. Oktober 2008, 13:56
- 15
- Wohnort: 91463 Dietersheim
Re: Update 18.1.1
Hallo,Kasimir hat geschrieben: ... Bei mir steht in dessen "Eigenschaften" (unter Verwaltung/Dienste):
C:\TurboMed\Programm\FastObjects64\FastObjectsServer64.exe -config "ptserver.cfg"
Also es steht hinter "config" kein Laufwerksbuchstabe. Beim 32-bit-FOS steht jedoch einer.
Vielleicht ist das die Ursache, dass der 64erFOS die Dictionary nicht finden kann. Aber: Wo und wie kann ich das ändern?
das wäre schon möglich, da der FOS bei Ihrer Konfigurationszeile möglicherweise nicht die richtige oder gar keine ptserver.cfg findet. Der Dienst zeigt ja wohl keine Fehlermeldungen an. ich habe zumindest bisher nichts gefunden.
Das sicherste ist, in der Registry nach "ptserver.cfg" zu suchen, wie rfbdoc weiter oben in diesem Thread das bereits beschrieben hat
Bei mir in der Registry habe ich 3 Treffer in den Schlüsseln:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\FastObjects Server (x64) 11.0,
Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\FastObjects Server (x64) 11.0 und
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FastObjects Server (x64) 11.0
steht jeweils unter ImagePath der Eintrag:
E:\Turbomed\Programm\FastObjects64\FastObjectsServer64.exe -config "e:\turbomed\Programm\ptserver.cfg"
Sie müßten also mit regedit.exe (als Administrator oder im Administratorkonto ausführen) nach "ptserver.cfg" suchen, an der Fundstelle sollte der Cursor automatisch auf dem Wort "ImagePath" vor der entsprechenden Konfigurationszeile (im rechten Regedit-Fenster) liegen: mit Enter oder Doppelklick öffnet sich ein Bearbeitungsfenster: hier können Sie zwischen config " und ptserver.cfg" den fehlenden Pfadteil c:\turbomed\Programm\ einfügen.
Natürlich sollten in der c:\turbomed\Programm\ptserver.cfg dann auch die richtigen Einträge stehen, da bei Ihnen der 32Bit FOS korrekt läuft (und dieser auch diese ptserver.cfg benutzt), müßte das aber passen.
Gruß
FranzKonrad
Re: Update 18.1.1
Nach Update auf 18.1.1 mit dem Patch das die Fehler des Updates korrigiert startet IFAP zwanghaft mit TM und lässt sich auch nicht schliessen nur in den Hintergrund verdammen. Gibt es dafür eine Lösung? Oder muss ich mit IFAP-Zwangsstart leben?
Martin H.
Re: Update 18.1.1
Nachtrag: über den Taskmgr lässt sich IFAP natürlich stoppen und TM läuft weiter.
Das Problem tritt auch nur an den Terminalserverclients auf. Insofern kann man damit leben.
Das Problem tritt auch nur an den Terminalserverclients auf. Insofern kann man damit leben.
Martin H.
Re: Update 18.1.1
Es gibt noch eine andere Lösung:
nach dem Start von TM geht man bei einem beliebigen Patienten in F8 und ruft aus der Medi-Liste mit Shift F9 IFAP auf, dann verschwindet IFAP aus dem Task, wird automatisch neu gestartet und nach dem Verlassen dann auch geschlossen. Also den Taskmgr muss man nicht bemühen, nur einmal innerhalb TM IFAP aufrufen und wieder schließen.
Updates sind eben fast immer für eine Überraschung gut
nach dem Start von TM geht man bei einem beliebigen Patienten in F8 und ruft aus der Medi-Liste mit Shift F9 IFAP auf, dann verschwindet IFAP aus dem Task, wird automatisch neu gestartet und nach dem Verlassen dann auch geschlossen. Also den Taskmgr muss man nicht bemühen, nur einmal innerhalb TM IFAP aufrufen und wieder schließen.
Updates sind eben fast immer für eine Überraschung gut
Martin H.
Re: Update 18.1.1
Zitat:
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 ???
Wir müssen nach jedem Update oder Patch an allen Stationen, TM als Administrator starten, und dann ein BG-Formular öffnen und wie der schließen, sonst kommt o.g. Fehlermeldung. Das ist bei uns schon seit einigen Jahren so. Wichtig noch: der PC mußß einen Internetzugang haben bei dieser Aktion, warum auch immer. Dann geht alles.
Gruß Nobbie
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 ???
Wir müssen nach jedem Update oder Patch an allen Stationen, TM als Administrator starten, und dann ein BG-Formular öffnen und wie der schließen, sonst kommt o.g. Fehlermeldung. Das ist bei uns schon seit einigen Jahren so. Wichtig noch: der PC mußß einen Internetzugang haben bei dieser Aktion, warum auch immer. Dann geht alles.
Gruß Nobbie
Gruß Nobbie
Ich werde keine frühe Turbomed - Downloadversion installieren
Ich werde keine frühe Turbomed - Downloadversion installieren
-
- Beiträge: 69
- Registriert: Samstag 1. August 2009, 11:46
- 14
Re: Update 18.1.1
Guten Morgen! Mal was Positives zum Quartalsupdate von meiner Seite:
nachdem ich beim letzten Quartalsupdate (IV 2017) massive Probleme durch Konflikte zwischen dem Gyn-Center und dem PraxisArchiv hatte, die einen normalen Betrieb durch gegenseitige Blockade der Clients unmöglich gemacht haben und von meinem IT-ler nur dadurch behoben werden konnten, dass das GynCenter auf den Stand vor dem Update zurückgesetzt wurde, scheint durch das aktuell Update dieses Problem behoben worden zu sein.
Auffällig war bei mir eine extreme Dauer des Updates der PraxisDB: normalerweise läuft die bei mir (nach 15 Jahren TM) in 20-30 min durch; gestern 3 Stunden (!) (und mein Server ist nicht der langsamste).
Offenbar wurde da im Hintergrund Konflikte (in den Karteikarteneinträgen?) bezüglich des genannten Problems behoben, anders kann ich mir nicht erklären, warum diese lange Dauer von anderen Anwendern hier nicht berichtet wurde. Die Konstellation GynCenter + PraxisArchiv dürfte im Anwenderkreis von TM wohl nur an Häufigkeit im unteren dreistelligen Bereich vorkommen und daher die Mehrzahl der Anwender nicht betreffen.
Schön, dass jetzt auf einmal alles wie gewünscht funktioniert.
Schade, das TM trotz mehrfacher Nennung des Problems durch mich im Forum und auch nach einer direkten Mail an den TM-Service offenbar nicht den Mut hatte, zu reagieren und einen Fehler zuzugeben, sondern das Problem wir auch immer klammheimlich beseitigt hat, ohne das zu kommunizieren. Kundenorientierung sieht anders aus.
nachdem ich beim letzten Quartalsupdate (IV 2017) massive Probleme durch Konflikte zwischen dem Gyn-Center und dem PraxisArchiv hatte, die einen normalen Betrieb durch gegenseitige Blockade der Clients unmöglich gemacht haben und von meinem IT-ler nur dadurch behoben werden konnten, dass das GynCenter auf den Stand vor dem Update zurückgesetzt wurde, scheint durch das aktuell Update dieses Problem behoben worden zu sein.
Auffällig war bei mir eine extreme Dauer des Updates der PraxisDB: normalerweise läuft die bei mir (nach 15 Jahren TM) in 20-30 min durch; gestern 3 Stunden (!) (und mein Server ist nicht der langsamste).
Offenbar wurde da im Hintergrund Konflikte (in den Karteikarteneinträgen?) bezüglich des genannten Problems behoben, anders kann ich mir nicht erklären, warum diese lange Dauer von anderen Anwendern hier nicht berichtet wurde. Die Konstellation GynCenter + PraxisArchiv dürfte im Anwenderkreis von TM wohl nur an Häufigkeit im unteren dreistelligen Bereich vorkommen und daher die Mehrzahl der Anwender nicht betreffen.
Schön, dass jetzt auf einmal alles wie gewünscht funktioniert.
Schade, das TM trotz mehrfacher Nennung des Problems durch mich im Forum und auch nach einer direkten Mail an den TM-Service offenbar nicht den Mut hatte, zu reagieren und einen Fehler zuzugeben, sondern das Problem wir auch immer klammheimlich beseitigt hat, ohne das zu kommunizieren. Kundenorientierung sieht anders aus.
Re: Update 18.1.1
Das alles wie gewünscht läuft kann ich nicht gerade sagen:
1. TM schmiert immer wieder mal auf den Clients ab, ist im laufenden Betrieb sehr ärgerlich.
2. Beim Aufrufen von Ziffernketten aus der Komplexsteuerung heraus hängt TM regelmäßig beim ersten BG-Patienten und PP-Patienten (jeden Tag 1 mal) so ca. 10-20 sec. mit weißem transparentem Bildschirm.
3. Das estellen von Rechnungen dauer gefühlt relativ lange.
4. Beim Start Abrechnung > Privatliquidation > Gesamterstellung kann man sich in aller Ruhe einen Kaffee holen bis das startet.
5. Beim reaktivieren eines alten BG-Falles bleibt die alte Krankenkasse hinterlegt auch wenn der Pat. aktuell eine neue Kasse hat (die Kasse muß im BG-Fall dann händisch geändert werden, was natürlich regelmäßig im laufendne Betrieb übersehen wird). Das bedeutet z.B., das eine AU neu gemacht werden muß.
6. Die Sicherung der eigenen Listen bricht bei uns seit einigen Updates ab und ist somit nicht mehr möglich.
ein paar Fehler, die mir so spontan einfallen.
1. TM schmiert immer wieder mal auf den Clients ab, ist im laufenden Betrieb sehr ärgerlich.
2. Beim Aufrufen von Ziffernketten aus der Komplexsteuerung heraus hängt TM regelmäßig beim ersten BG-Patienten und PP-Patienten (jeden Tag 1 mal) so ca. 10-20 sec. mit weißem transparentem Bildschirm.
3. Das estellen von Rechnungen dauer gefühlt relativ lange.
4. Beim Start Abrechnung > Privatliquidation > Gesamterstellung kann man sich in aller Ruhe einen Kaffee holen bis das startet.
5. Beim reaktivieren eines alten BG-Falles bleibt die alte Krankenkasse hinterlegt auch wenn der Pat. aktuell eine neue Kasse hat (die Kasse muß im BG-Fall dann händisch geändert werden, was natürlich regelmäßig im laufendne Betrieb übersehen wird). Das bedeutet z.B., das eine AU neu gemacht werden muß.
6. Die Sicherung der eigenen Listen bricht bei uns seit einigen Updates ab und ist somit nicht mehr möglich.
ein paar Fehler, die mir so spontan einfallen.
Gruß Nobbie
Ich werde keine frühe Turbomed - Downloadversion installieren
Ich werde keine frühe Turbomed - Downloadversion installieren
-
- Beiträge: 131
- Registriert: Sonntag 28. August 2016, 14:00
- 7
Re: Update 18.1.1
Etwa so lange (vielleicht etwas kürzer, sagen wir 2 Stunden) dauert die Datenbankaktualisierung bei uns schon immerJueHof hat geschrieben:Auffällig war bei mir eine extreme Dauer des Updates der PraxisDB: normalerweise läuft die bei mir (nach 15 Jahren TM) in 20-30 min durch; gestern 3 Stunden (!) (und mein Server ist nicht der langsamste).
Es gibt (nach den Version 18.1.1 3518, 3526 und 3534) seit gestern Abend übrigens das dritte Update 3544. Vielleicht werden die Probleme von anderen Kunden hier behoben...
-
- Beiträge: 30
- Registriert: Montag 24. März 2008, 20:12
- 16
- Wohnort: Oeversee bei FL
Re: Update 18.1.1
VIELEN DANK!!!!!!FranzKonrad hat geschrieben:Hallo,Kasimir hat geschrieben: ... Bei mir steht in dessen "Eigenschaften" (unter Verwaltung/Dienste):
C:\TurboMed\Programm\FastObjects64\FastObjectsServer64.exe -config "ptserver.cfg"
Also es steht hinter "config" kein Laufwerksbuchstabe. Beim 32-bit-FOS steht jedoch einer.
Vielleicht ist das die Ursache, dass der 64erFOS die Dictionary nicht finden kann. Aber: Wo und wie kann ich das ändern?
das wäre schon möglich, da der FOS bei Ihrer Konfigurationszeile möglicherweise nicht die richtige oder gar keine ptserver.cfg findet. Der Dienst zeigt ja wohl keine Fehlermeldungen an. ich habe zumindest bisher nichts gefunden.
Das sicherste ist, in der Registry nach "ptserver.cfg" zu suchen, wie rfbdoc weiter oben in diesem Thread das bereits beschrieben hat
Bei mir in der Registry habe ich 3 Treffer in den Schlüsseln:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\FastObjects Server (x64) 11.0,
Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\FastObjects Server (x64) 11.0 und
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FastObjects Server (x64) 11.0
steht jeweils unter ImagePath der Eintrag:
E:\Turbomed\Programm\FastObjects64\FastObjectsServer64.exe -config "e:\turbomed\Programm\ptserver.cfg"
Sie müßten also mit regedit.exe (als Administrator oder im Administratorkonto ausführen) nach "ptserver.cfg" suchen, an der Fundstelle sollte der Cursor automatisch auf dem Wort "ImagePath" vor der entsprechenden Konfigurationszeile (im rechten Regedit-Fenster) liegen: mit Enter oder Doppelklick öffnet sich ein Bearbeitungsfenster: hier können Sie zwischen config " und ptserver.cfg" den fehlenden Pfadteil c:\turbomed\Programm\ einfügen.
Natürlich sollten in der c:\turbomed\Programm\ptserver.cfg dann auch die richtigen Einträge stehen, da bei Ihnen der 32Bit FOS korrekt läuft (und dieser auch diese ptserver.cfg benutzt), müßte das aber passen.
Gruß
FranzKonrad
Auch bei mir lief der FOS nicht ... weder als 32bit noch als 64bit Variante. Auch bei mir stand kein kompletter Pfad hinter -config.
Nur durch Ändern der Einträge in der Registry habe ich es zum Laufen gebracht.
Gerade macht er die Reorganisation und den ganzen Kassen und Medi Krempel, dauert aber gefühlt ziemlich lange ... hoffentlich nur beim ersten Start...
DANKE an alle Mitstreiter! Ich kann mir nicht vorstellen, dass Montag früh die Hotline irgendwas gerissen hätte... wenn sie den rangegangen wäre...
LG von Clint
-
- PowerUser
- Beiträge: 1618
- Registriert: Mittwoch 11. Mai 2005, 20:23
- 18
- Wohnort: Land Brandenburg
- Hat sich bedankt: 3 times
- Bedankt: 25 times
Re: Update 18.1.1
Heute habe ich das Update 18.1.2. aufgespielt.
Danach war der FOS-Dienst wieder abgeschaltet. - Aber dank des Forums ist das ja kein Problem mehr gewesen.
Was aber funktioniert hat: Beim FOS64 war nun (nach dem Update) bei mir von ganz allein bei den "Eigenschaften" des Dienstes der richtige Pfad eingetragen (ich hatte bisher den Registry-Tipp von FranzKonrad noch nicht umgesetzt).
Danach war der FOS-Dienst wieder abgeschaltet. - Aber dank des Forums ist das ja kein Problem mehr gewesen.
Was aber funktioniert hat: Beim FOS64 war nun (nach dem Update) bei mir von ganz allein bei den "Eigenschaften" des Dienstes der richtige Pfad eingetragen (ich hatte bisher den Registry-Tipp von FranzKonrad noch nicht umgesetzt).
Viele Grüße
Kasimir
Kasimir
-
- PowerUser
- Beiträge: 2924
- Registriert: Sonntag 30. April 2006, 19:31
- 17
- Hat sich bedankt: 29 times
- Bedankt: 51 times
Re: Update 18.1.1
Auch nach Bearbeiten der Registry und Einstellung des Pfads zur Ptserver.cfg auf ..\TurboMed\Programm musste heute nach Update von 18.1. auf 18.2. der Fastobjectsserver auf dem Server manuell neu gestartet werden. Allerdings entfällt nun das sonst notwendige manuelle einkopieren der ptserver.cfg in das Verzweichnis Fastobjects64
Ungeklärt bleibt weiter warum das Update den FOS nicht wieder automatisch als Dienst einrichtet.
Ungeklärt bleibt weiter warum das Update den FOS nicht wieder automatisch als Dienst einrichtet.
R.F.B.
-
- Beiträge: 121
- Registriert: Samstag 2. April 2011, 19:32
- 13
Re: Update 18.1.1
Update aufgespielt, FOS manuell eingerichtet und noch ptserver.cfg in das Verzeichnis Fastobjectsserver hineinkopiert und alles läuft, aber jedesmal beim Neustart nicht mehr, obwohl der FOS aktiviert ist !
Dann müsste über die Systemsteuerung / Verwaltung / Dienste der FOS erst mal wieder gestoppt werden, danach die hier allseits bekannte manuelle FOS Einrichtung.. und alles läuft wieder.
Hat jemand eine Idee, wie man dieses Problem dauerhaft beheben kann ?
Im Moment lasse ich der Server einfach immer an.
Dann müsste über die Systemsteuerung / Verwaltung / Dienste der FOS erst mal wieder gestoppt werden, danach die hier allseits bekannte manuelle FOS Einrichtung.. und alles läuft wieder.
Hat jemand eine Idee, wie man dieses Problem dauerhaft beheben kann ?
Im Moment lasse ich der Server einfach immer an.
Re: Update 18.1.1
Hi,
hatten wir auch mal vor langer Zeit, dass der FOS als Dienst nicht funktionierte. Wir haben den damals am Server manuell gestartet (als Administrator) und einfach laufen lassen, dann ging es. Irgendwann lief der dann auch wieder als Dienst.
Gruß Nobbie
hatten wir auch mal vor langer Zeit, dass der FOS als Dienst nicht funktionierte. Wir haben den damals am Server manuell gestartet (als Administrator) und einfach laufen lassen, dann ging es. Irgendwann lief der dann auch wieder als Dienst.
Gruß Nobbie
Gruß Nobbie
Ich werde keine frühe Turbomed - Downloadversion installieren
Ich werde keine frühe Turbomed - Downloadversion installieren
Re: Update 18.1.1
Den Server lassen wir sowieso durchlaufen, der macht nachts jede Menge, Datensicherungen, Serversicherung etc. Das Anlassen des Servers soll laut Aussage meiner EDV-Firma für die Hardware auch "gesünder" sein.
Gruß Nobbie
Ich werde keine frühe Turbomed - Downloadversion installieren
Ich werde keine frühe Turbomed - Downloadversion installieren
-
- Beiträge: 291
- Registriert: Donnerstag 4. Oktober 2012, 13:32
- 11
- Hat sich bedankt: 11 times
- Bedankt: 24 times
Re: Update 18.1.1
Führt außerdem zur Sanierung der Elektrizitätswerke auf Kosten der UmweltNobbie hat geschrieben:Den Server lassen wir sowieso durchlaufen, der macht nachts jede Menge, Datensicherungen, Serversicherung etc. Das Anlassen des Servers soll laut Aussage meiner EDV-Firma für die Hardware auch "gesünder" sein.
Re: Update 18.1.1
Das mit den E-Werken ist leider wahr. Aber ein Serverstart, bis der richtig läuft, dauert mindestens 15 min.! Und die "Wartungsarbeiten" kann man schlecht im laufenden Betrieb machen, dann ist TM noch langsamer.
Gruß Nobbie
Ich werde keine frühe Turbomed - Downloadversion installieren
Ich werde keine frühe Turbomed - Downloadversion installieren
Wer ist online?
Mitglieder in diesem Forum: piccolo1108 und 65 Gäste