Seite 1 von 1

CacheDB bei anderem FastObjectsServer Port möglich?

Verfasst: Sonntag 10. Mai 2015, 23:26
von Traindriver316
Hallo,

so langsam bin ich doch verzweifelt, da es einfach nicht Möglich ist den CacheDB Modus zu aktivieren, wenn man den Standard FastObjectsServer Port geändert hat.

Wir betreiben einen Windows SBS 2011 und können den Standardport nicht nutzen, deswegen haben wir diesen geändert. Nur leider kann ich den CacheDB Modus nicht aktivieren, da ich immer wieder diese Fehlermeldung erhalte:
Am 10.05.2015 um 23:22:02 Uhr wurden
folgende Aktionen ausgefuehrt ...

Server: localhost
Datenbank: PraxisDB
Fehler beim Oeffnen der Datenbank: -2506
The communication link is broken.

Der externe Backupmodus der Datenbank PraxisDB wurde erfolgreich gestartet.

Die Datei 'd:\TurboMed\PraxisDB\objects.dat' wird in den Systemcache geladen ...
... das Laden wurde erfolgreich abgeschlossen.

Die Datei 'd:\TurboMed\PraxisDB\objects.idx' wird in den Systemcache geladen ...
... das Laden wurde erfolgreich abgeschlossen.

Der externe Backupmodus der Datenbank PraxisDB wurde erfolgreich beendet.
ptserver.cfg
useLicenses=PraxisServer
service=10101

poet.cfg
[servers\PraxisServer]
name=server
service=10101/tcp
[servers\StammServer]
name=server
service=10101/tcp
[servers\DruckServer]
name=server
service=10101/tcp
[servers\server]
service=10101/tcp

Auf eine Antwort von Turbomed direkt werden ich wahrscheinlich noch Ewigkeiten warten müssen, da sich innerhalb einer Woche und nach mehreren Nachfragen bis jetzt keiner gemeldet hat :-(

Vielleicht hat der ein oder andere einen Tipp. Vielen Dank im Voraus.

Re: CacheDB bei anderem FastObjectsServer Port möglich?

Verfasst: Montag 11. Mai 2015, 08:45
von Meckelein
Nunja, die Erklärung hierfür ist an sich ganz simpel, auch wenn dies ausserhalb von CGM niemand bestätigen können wird.

Das Program "TMAdmin.exe" stammt von CGM selber und benutzt nur den Standardport um uf die DB zuzugreifen. Es wird nicht geprüft, ob in den Config Dateien "ptserver.cfg" oder "poet.cfg" ein anderer Port angegeben wurde. Dagegen ist die "FastObjectsServer.exe" die die Datenbank startet, direkt vom Hersteller, in diesem Fall "Versant Corporation Inc." übernommen und daher in der Lage sämtliche Parameter aus den Config Dateien auszulesen und hiermit zu arbeiten.

Da aber die Dateien trotzdem in den Cache geladen werden, auch wenn ein Zugriff auf die DB fehl schlägt, gehe ich davon aus, dass dies auch so ist. Sie sollten mal prüfen, ob sich die Arbeitsgeschwindigkeit erhöht und mehr Arbeitsspeicher verbraucht wird, nachdem Sie die Datenbank in den Cache geladen haben. Aufgrund der Meldungen ist davon auszugehen, dass trotz mangelhafter Fehlerprüfung von CGM, die Daten in den Cache geladen werden.

Re: CacheDB bei anderem FastObjectsServer Port möglich?

Verfasst: Montag 11. Mai 2015, 22:07
von rfbdoc
Läut der FOS mit Administratorrechten ?
(Mit dem Explorer im Ordner TurboMed\Programm\ die Dateien FastObjectsServer.exe aufsuchen.
Über rechte Maustaste→ Eigenschaften im Register "Kompatibilität" ganz unten "Einstellungen für alle Benutzer ändern". Im nächsten Fenster "Programm als Administrator ausführen" aktivieren, dann Neustart)

Steht die PtServer.cfg im richtigen Verzeichnis ?
32bit: \TurboMed\Programm\
64bit: \TurboMed\Programm\FastObjects64\

Re: CacheDB bei anderem FastObjectsServer Port möglich?

Verfasst: Montag 11. Mai 2015, 23:03
von Traindriver316
Hallo vielen Dank für die zahlreichen Tips,

ich habe nun nochmal die PtServer.cfg kontrolliert, die sich im Verzeichnis: TurboMed\Programm\FastObjects64 befindet und diese scheint korrekt konfiguriert zu sein.

Der FastObjectsServer wird als Dienst geladen, somit läuft er schon mit Adminrechten.

Er lädt zwar den Arbeitsspeicher mit ca. 3 GB voll aber dann entlädt er diesen sobald das cachen beendet wurde mit der Meldung:

folgende Aktionen ausgefuehrt ...


Server: localhost
Datenbank: PraxisDB
Fehler beim Oeffnen der Datenbank: -2506
The communication link is broken.

Server: localhost:10101
Datenbank: PraxisDB

Die Datei 'd:\TurboMed\PraxisDB\objects.dat' wird in den Systemcache geladen ...
... das Laden wurde erfolgreich abgeschlossen.

Die Datei 'd:\TurboMed\PraxisDB\objects.idx' wird in den Systemcache geladen ...
... das Laden wurde erfolgreich abgeschlossen.

Vielen Dank auf jeden Fall für die Hilfestellungen. Ansonsten werden wir den TM Server auf einen anderen VServer umziehen, sollte dies nicht klappen, da von Turbomed direkt anscheinend kein Update kommen wird. :-)

Re: CacheDB bei anderem FastObjectsServer Port möglich?

Verfasst: Mittwoch 13. Mai 2015, 12:17
von lapins
2007 hat "Thomas" eh schon alles beschrieben wie das mit dem cachen ist.

http://www.vondoczudoc.de/viewtopic.php ... satz#p5213

Also das TM Programm liest einmal die DB durch und sonst passiert nix. Wenn sie genug freien Speicher haben wird die DB dort "gelagert".

Wenn das so ist, wie es Thomas beschrieben hat, passiert dasselbe aber auch do nach und nach im Tagesbetrieb - ohne dass sie was dazutun! ---
Wenn sie genug freien Speicher haben.

Wie können sie das sehen? Ich hab vor Zeiten da mal im Internet recherchiert und fast alle Details wieder vergessen bis auf das worauf es ankommt:

Sie holen sich den Process Explorer von Microsoft - starten und schauen sich die System-Information an . Da wieder die Memory siehe Bild.
150513Processexplorer.JPG
Sie Brauchen nur lächerliche 3 Zahlen betrachten:

Physical Memory
Total : 8195.xxx

Commit Charge Current / Peak
5561xxx /6732xxx

Größe der praxisdb im Verzeichnoss turbomed\praxisdb objects.dat+ idx zB 3000xxx

Jetzt müssen sie nur noch wissen, dass der Windows-Cache eben NICHT im COMMIT Charge liegt , sondern im Rest der Memory .

+8195
-5561
=2634 < 3000 also theoretisch bräuchte ich ein wenig mehr Memory.

Im konkreten Fall sind das Werte von meinem System wo gerade folgendes läuft:

7 User per RDP (also nicht nur der Fast-object)
unter anderem mit

7 x TM + praxiscenter

7 x Iexplore
googledrivesync
HAEVG-HZV Modul
Open vpn
4 x thumbs ( so was wie irfan )
ggf word, fritzfaxviewer

+ ggf Batch im Hintergrund zum Sichern an die Nachbarpc's bzw encrypted in googledrive

.... und trotzdem ist bei "nur" 8gb genug Platz für die DB.

PEAK: Sie sehen dass der Peak während des Betriebes mal höher war 6732xxx . Wahrscheinlich während eine 7z zip Sicherungsprozess.

Es flutscht bei rdp auch - egal ob lokal oder übers Internet.

Ich habe eine 256gb Samsung 840 Pro SSD
c: ...48GB
f: 190gb aber noch 120gb frei

Mit mehr RAM wären vielleich noch 0,1 sek ?? bessere Zeiten möglich??? aber glauben sie mir, alle Optimierungen der Karteikarte wie zB nur 100 Tage anzeigen
oder "nicht sortieren " der Einträge oder Datum in jeder Zeile usw usw ist alles nicht notwendig- es flutscht.


Also einfach SSD , eventuell genug FREIER speicher und nix-tun
mfg rLAP