Fehler beim Öffnen der Datenbank"StammDB"

[riesdoc]

Trotz Durchforsten des Forums konnte ich keine Lösung für folgendes (ziemlich drängendes) Problem finden:

Aktuell lief TM Vers. 10.4.0 problemlos auf Server + 3 Arbeitsplätzen. Vor ca. 1 Woche wollte TM nicht starten, weil der Poet nicht getartet sei. Dem Zeitmangel geschuldet wurde dieser einfach als Arbeitsschritt 1 manuell gestartet, alles lief ansonsten wie gewohnt. Da der gestrige Versuch einfach den FastObj.Server in den Autostart zu ziehen beim reboot mit der Meldung einer fehlenden .dll quittiert wurde, legte ich die aktuelle TM-DVD ein und installierte Vers. 10.4.1.

Leider erschien nun beim Versuch TM zu starten die Meldung: Fehler beim Öffnen der Datenbank "StammDB" (Pfad C:\...)
DB Kernel Error: Cannot access or create data dump file. (-2773)

Der Vorschlag der TM-Hotline, den Eventlog-Ordner in EventlogAlt umzubennen und dann einen erneuten Start zu versuchen schlug leider fehl.

Da sich TM jedoch bei Start in Einzelplatzkonfiguration am Server problemlos starten lässt, vermute ich tatsächlich ein ein Problem mit dem Poeten!?

Weiss jemand Rat?

[rfbdoc]

Nach dem manuellen Start des Fastobjektservers habe ich ihn nicht in die Autostart gezogen sondern über Rechte Maustaste Fastobjektserver als Dienst starten automatisiert

[wahnfried]

Nach dem manuellen Start des Fastobjektservers habe ich ihn nicht in die Autostart gezogen sondern über Rechte Maustaste Fastobjektserver als Dienst starten automatisiert

...man kann auch in der Diensteverwaltung (erreichbar über "Systemsteuerung - Verwaltung - Computerverwaltung") nachschauen, dort müßte der Dienst "FastObjectsServer 10.x" bereits eingetragen sein, dort die Startart (nach rechtem Mausklick: Eigenschaften) auf "Automatisch" stellen und den Dienst dann entweder gleich starten oder durch Reboot das automatisierte Starten gleich testen.

(rechten Mausklick auf das "F" im Systray mache ich nur, wenn der FOS als Dienst zum allerersten Mal eingerichtet werden soll und noch nie als Dienst konfiguriert war.)

Grüsse, Wahnfried

[wahnfried]

... wollte TM nicht starten, weil der Poet nicht getartet sei. Dem Zeitmangel geschuldet wurde dieser einfach als Arbeitsschritt 1 manuell gestartet...

Hallo riesdoc,

das heißt wohl, Doppelklick auf die Datei "PtServ32.exe" oder "FastObjectsServer.exe" im Ordner TurboMed/Programm?

Bei welchem Arbeitsschritt kam denn dann die Fehl-meldung betr. der DLL? Wenn der Dienst bereits einmal eingerichtet gewesen ist (was ich bei einem bisher gut laufenden System vermuten würde), sollten eigentlich alle benötigten Hilfs-Dateien bereits registriert gewesen sein...

Trotzdem ist für den FOS der Windows-Autostart-Ordner die falsche Adresse. Kann ich aber nicht weiter begründen . Es könnte aber sein, daß ein FOS-Start via Autostart-Ordner sogar mit der "PtServ32.exe" geht (und evtl. nur nicht mit der eigentlichen Programmdatei), da erstere ein "FastObjects Server 10 Starter" ist.

Ansonsten siehe die beiden vorigen Beiträge...

Grüsse, Wahnfried

[riesdoc]

Hallo und Dank für die bisherigen Antworten.

Die .dll Meldung kam damals direkt nach dem Systemstart nachdem die vermeintliche Autostart-Lösung von mir versucht wurde.

Inzwischen bin ich mir aber bzgl. FOS und der oben beschriebenen Fehlermeldung nicht mehr so ganz sicher, da ich zwischenzeitlich alle FOS-Einträge aus der Registry gelöscht habe, den FOS anschließend manuell gestartet und als Service konfiguriert habe sowie in der Dienste-Verwaltung FOS als gestartet gecheckt habe (mit automatischem Start):

Die Fehlermeldung bzgl. DB Kernel Error (s.o.) bleibt bestehen...

[mschiller]

mal ne dumme frage zwischenrein: wenn einzelplatz funktioniert mit version 10.4.1, auf dem client von dem die fehlermeldung kommt ist aber schon auch 10.4.1 installiert und nicht die alte version, oder?

[riesdoc]

Dumme Fragen gibt´s doch nicht, oder?

Nein, die Version ist 10.4.1. Die Situation ist so, dass der Server gleichzeitig auch Arbeitsplatz ist. Ändere ich nun in der local.ini den Eintrag "Mehrplatzbetrieb" in nein, sprich nun also Einzelplatzbetrieb, so öffnet sich TM und die StammDB brav, bei Eintag Mehrplatzbetrieb Ja bin ich wieder bei obigem Problem.

Ich bin wirklich für jede Nachfrage und Rat dankbar.

[Johnny]

@riesdoc,

beachten Sie nochmals die Fehlermeldung!

Sind alle Pfade in den Grundeinstellungen zum Server richtig gesetzt?

Gruß aus Kiel

Johnny

[wahnfried]

beachten Sie nochmals die Fehlermeldung!

Sind alle Pfade in den Grundeinstellungen zum Server richtig gesetzt?

...insbesondere der genaue Name der fehlend bemängelten .dll nach dem Reboot wäre wichtig, um das Problem einzugrenzen.
Der Systemstart ist ja Windows-Sache, insofern auch Frage: welches Windows..., evtl. auch mal protokollierten Start, um nachzusehen, in welchem Zusammenhang die fehlend bemängelte .dll zu laden versucht wird. Wenn das im Zusammenhang mit dem Start des FOS-Dienstes erfolgt, könnte es sein, daß der FOS nicht korrekt läuft. Das wäre beim Einzelplatz-Start von TurboMed unwichtig, nicht aber beim Server-Start. Dann dürfte auch kein Client auf die TurboMed-Datenbanken des Servers zugreifen können (auch kein neu konfigurierter), aaaaber: es müsste/könnte der Server - als Versuchs-Client konfiguriert - via auf einem Ex-Client (modusgewechselt zum Einzelplatz und dann dort Datenspiegelung und schließlich Umwidmung zum Server) laufendem FOS auf die dortigen TurboMed-Datenbanken zugreifen (also versuchsweise einfach mal Rollentausch zwischen Client und Server, vorher ursprüngliche Lokal.ini und Global.ini sichern...).

"Data dump file nicht erzeugbar oder zugreifbar" heißt wohl, daß beim Versuch des Zugriffs auf die StammDB eine Protokolldatei zum Eingrenzen des Fehlers erzeugt werden sollte und auch dies mißlungen ist?

Noch eine Nicht-dumme-Frage: der Servername ist in den Grundeinstellungen am Server wirklich korrekt eingetragen? Vielleicht einfach mal ein Bit umgesprungen?

(Ein Image vom korrekt laufenden Server-Betriebssystem-Zustand haben Sie aber hoffentlich? Das wäre die radikale Lösung, jedoch ohne Klärung der Ursache des Fehlers...)

Grüsse, Wahnfried

[riesdoc]

Vielen Dank allen Mitdenkern!

Leider konnte ich erst jetzt wieder ins Forum schauen, sonst hätte ich bereits eher reagiert. Nachdem sich gestern keine Lösung abzuzeichnen schien, kam angesichts aufkeimender Zukunftspanik die (von Wahnfried auch beschriebene) Radikallösung gegen 19.00 Uhr zum Einsatz: dem Image sei´s gedankt, konnte heute der Schlado (Sch.. langer Donnerstag) problemlos durchgenudelt werden. Leider konnte so der Fehler nicht isoliert werden, aber Hausarzt heisst auch Praktiker/Pragmatiker zu sein...

Nochmals herzlichen Dank von riesdoc