VonDoczuDoc.de

Guten Tag,

seit ein paar Tagen stürzt TM mit diesem Fehler ab.

"Fehler beim Laden des Objekts "PraxisDB$....." vom Typ "KarteikartenZeile": DB Kernel Error: The communication link is broken (-2506)"

Man konnte max. 1 Stunde arbeiten bis zu dem Fehler (im bunten TM-Design), bei dem Wartungsdialog "Praxisdatenbank prüfen" hat es meist nach 15 Minuten gekracht.

Nach dem ersten Tag Remote-Support aus Kiel haben diese erstmal aufgegeben und meinten "vielleicht hilft ja eine Neuinstallation". Die ist heute erfolgt, PraxisDB etc. wieder importiert und DB-Prüfung nochmal gestartet... Jetzt:
Microsoft Visual C++ Runtime Library, Runtime Error: https://www.dropbox.com/s/75oi7c5ezhepvuo/tm2.PNG?dl=0

Irgendwelche kreativen Ideen, was man versuchen könnte? Vielen Dank im Voraus!

Der Fehler 2506 steht eigentlich für ein Netzwerkproblem. Es könnte auch sein, dass der FastObjectServer abstürzt. Dazu fehlen jedoch weitere Angaben.
Wenn sich die Datenbank nicht reorganisieren oder prüfen lässt, dann kopieren Sie die Datenbank auf einen Client und führen Sie diese Aufgaben im Einzelplatzbetrieb durch. Sollte die Datenbank fehlerfrei sein, kann sie wieder auf den Server kopiert werden.
HansW

Ja, klingt nach Netzwerk nur dass kein Netzwerk dazwischen ist in dem Fall.

Bei einer versuchten Reindizierung auf dem Server ist er grad wieder abgestürzt. Ich versuche jetzt mal Ihre Idee mit dem Kopieren auf einen anderen PC

Da das Absturzverhalten stark mit der Version schwankt die Frage nach der verwendeten genauen Version.
Von der 17.4.1.xxxx gab es ja gleich drei Varianten.

Sobald der Fehler da ist, können Sie dann mittels Fileexplorers auf \\Server (Rechnername des TM Servers) incl. Unterverzeichnisse zugreifen ?
Falls nein, Netzwerkproblem, evtl. keine User/Passwort Zugangsrechte.

hofeBY hat geschrieben:Da das Absturzverhalten stark mit der Version schwankt die Frage nach der verwendeten genauen Version.
Von der 17.4.1.xxxx gab es ja gleich drei Varianten.

Sobald der Fehler da ist, können Sie dann mittels Fileexplorers auf \\Server (Rechnername des TM Servers) incl. Unterverzeichnisse zugreifen ?
Falls nein, Netzwerkproblem, evtl. keine User/Passwort Zugangsrechte.

Es ist die 17.4.1.3481...vielleicht hilft ja die Flucht nach vorne auf die 18.1...
Letzteres habe ich nicht ausprobiert, da ja garkein Netzwerk dazwischen ist (TM ist auf dem Terminalserver selbst installiert, d.h. Software, Datenbank und TM-Verzeichnis befinden sich auf der gleichen Maschine)

Nun, die 17.4.1.3481 ist die aktuelle. Die läuft bei uns ... einigermaßen stabil.

Gut nun zum zweiten Ansatzpunkt der Namensauflösung:
Nur weil TM und gestartete Clientanwendung (TM) auf dem gleichen Rechner ablaufen,
heißt das nicht, das sie nicht über die Netzwerkumgebung kommuniezieren.
Selbst wenn noch nichtmal eine Netwerkkarte existiert.

CMD Fenster starten
"ipconfig /all"
Prüfen ob Sie ein Interface mit der IP-Adresse 127.0.0.1 finden. Nööö nicht da, aber ein "ping -t 127.0.0.1" geht trotzdem.
Und das sogar bei allen abgezogenen Netzwerkkabeln.

Genau, also trotzdem Netzwerk vorhanden. Schimpft sich "LocalLoopback Kurzform lo".

Zusätzlich muss man wissen, das es immer einen Serverteil und einen Clientteil unter MS gibt.
Und wenn die nicht sauber miteinander können, gibt´s solche Effekte. Man denke an gespaltene Persönlichkeiten.

Was ergibt ein "nslookup server" ?
Falls kein positives Ergebnis würde ich den WINS Dienst im Serverteil aktivieren und die IP 127.0.0.1 in der Netzwerkumgebung des Clientanteils diese
Maschine als ersten WINS Server eintragen. WINS (Windows Internet Naming Service) [Micisoft selbstlernender möchtegern DNS Server]

Der Fehler beim Laden des Objekts vom Typ Karteikartenzeile - ist doch der Hinweis, dass ein Objekt = Patient eine fehlerhafte Karteikarte besitzt.
Besorgniserregend ist die DB-Prüfung die abbricht.

Als erstes Datensicherung der PraxisDB - damit dieser Zustand erstmal festgehalten wird.
Dann TurboMed Datenbank beenden und den Server in den Einzelplatz stellen - Grundeinstellungen - Verzeichnisse - Mehrplatzbetrieb auf "Nein" stellen - Haken raus.
Fast Object Server beenden.
Dann TurboMed /reorg über den command prompt als Administrator bitte ausführen.
Danach TurboMed starten und eine Prüfung der DB anstoßen.
Sollte nun der Gleiche Fehler entstehen Abbruch der Prüfung also, dann muss es dort auch einen Fehler mit Meldung geben.
Lassen Sie den Server ruhig in Ruhe laufen.
Ach ja, gehen Sie mal in den Support Ordner unter TurboMed auf dem Terminalserver und erstellen dort einen unterordner namens sicherung und legen dort alle .txt Dateien rein.
Dann haben Sie eine bessere Übersicht, was bei der Prüfung für ein Fehler entstanden ist.

So sollte die Prüfung durchgelaufen sein ohne Absturz, dann erstmal wieder eine Sicherung der PraxisDB weglegen.
Nun starten wir wieder TurboMed und gehen auf die Konsistenzprüfung der Datenbank, das dauert durchaus lange - danach bekommen Sie eine Auflistung wieviele Inkosistenzen in der DB gefunden wurden und welche behoben werden konnten.

In dem Support Ordner haben Sie eine TXT Datei in der Sie nachlesen können, falls die Auflistung nicht aufgelistet werden kann.

Sollte dies durchgelaufen sein, dann wieder die DB sichern.
Als letztes noch einmal die Praxisdatenbank prüfen und schauen ob es Probleme mit der DB gibt.

Meiner Meinung nach haben Sie Probleme mit der Datenbank, die nur von TurboMed selbst per Skript behoben werden können - aber man lernt ja nie aus

)

Mit freundlichen Grüßen

Hi,

vielen Dank für die Antworten - ich arbeite sie mal ab

CMD Fenster starten
"ipconfig /all"

Kein 127.0.0.1, nur die "normale" Adresse aus dem Netzwerk

Code: Alles auswählen

Ethernet-Adapter Ethernet:

   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft Hyper-V-Netzwerkadapter
   Physische Adresse . . . . . . . . : 00-15-5D-0A-50-01
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::dd9f:cbc0:7a37:92bf%12(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 172.18.1.11(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.0.0
   Standardgateway . . . . . . . . . : 172.18.1.1
   DHCPv6-IAID . . . . . . . . . . . : 251663709
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-19-8C-30-72-00-15-5D-0A-50-01

   DNS-Server  . . . . . . . . . . . : 172.18.1.10
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Tunneladapter isatap.{85825642-EA45-400D-899E-8E9CE6BB20C3}:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #5
   Physische Adresse . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja

Was ergibt ein "nslookup server" ?

Der DNS Server antwortet mit der passenden IP.

Der Fehler beim Laden des Objekts vom Typ Karteikartenzeile - ist doch der Hinweis, dass ein Objekt = Patient eine fehlerhafte Karteikarte besitzt.
Besorgniserregend ist die DB-Prüfung die abbricht.

Ich habe TM als Einzelplatz-Variante auf einem PC installiert und PraxisDB+StammDB rüberkopiert. Auf diesem PC ist die DB-Prüfung ohne Fehler durchgelaufen. Auch lief dieser Arbeitsplatz einen kompletten Tag ohne Absturz (auf dem Server geht max. 1 Stunde).
--> Daraus schließe ich, die DB scheint an sich in Ordnung zu sein, aber irgendwas an der Umgebung/Installation ist defekt oder inkompatibel.
Neuinstallation hat Turbomed schon versucht... Der Runtime-Error kommt ja aus der Visual C++ Runtime Library.... in der Systemsteuerung sind dort eine ganze Reihe Versionen zu finden. Folgende habe ich: https://www.dropbox.com/s/w7hbrduuiksni8b/libs.PNG?dl=0
Der Support meinte auf Anfrage "Lassen sie die lieber alle drin, hier weiß auch niemand so genau, welche gebraucht werden"

-----

Nach der TM Installation hatte der Support nur den Praxis-DB Ordner aus der Sicherung zurückgespielt. --> der DB Kernel Error
Ich habe dann mal noch den StammDB Ordner dazu genommen --> Reindizierung erfolgreich, bei Reorganisation kommt der Runtime Error
(Warum kopieren die nur den PRaxisDB Ordner? Ist der StammDB Ordner nicht auch essentiell?)

Übrigens: Bei den Abstürzen während der DB-Prüfung mit dem Kernel-Error werden auch keine Logfiles in den Support-Ordner geschrieben, komplett leer. Auch sieht es so aus, als hätte die DB Prüfung noch gar nicht richtig angefangen (Statusbalken steht auf 0).

Da TM und FOS sehr viel im Speicher arbeiten, würde ich auch dies durchlaufen lassen:

Memtest86+ - Speicher-Test-Tool
http://winfuture.de/downloadvorschalt,1248.html
Der Windows-speicherdiagnose traue ich nicht mehr. Hatte hier eine Box, bei der WIndows-Updates nicht funktionierten, aber alles Andere (auch TM und weitere neu installierte Programme).
Memtest hat dann Mengen an Fehlern gefunden. Speicherriegel gegen baugleichen Artikel aus gleicher Lieferung getauscht: Alles läuft fein (inkl. Memtest).

Speicherfehler zeigen manchmal skurrile und schwer herzuleitende Symptome.

Nachtrag: Ich habe die ISO-Datei (zum Brennen - siehe Beschreibung auf der Seite) verlinkt, da das Tool von einer bootfähigen CD gestartet werden muss.

Hi,

Der Server hat ECC Ram verbaut, keine Fehler-Einträge im Systemlog... wäre zudem irgendwie komisch, dass es zufällig immer die gleiche VM bei den gleichen Aktionen trifft.
Ich tippe eher auf ein Software-Problem...

Viele Grüße

Aktueller Stand:

Neue virtuelle Maschine installiert inkl. neuem Betriebssystem und TM... sah erst gut aus, nun ist die Fehlermeldung aber zurück. Kommt nicht mehr so häufig, aber tritt noch auf (u.A. bei Konsistenzprüfung).

Gibt es noch irgendwelche Ideen? Falls jemand einen echten TM-Experten kennt, gerne per PM. Mittlerweile steht die Praxis schon eine ganze Weile still und die offiziellen TM-Partner konnten nicht helfen.

OK, Namensauflösung war´s also nicht.

Virtuelle Maschine ist evtl. eine nicht unwichtige Info.

VMware ESXi Server. Version ? Lizensiert mit Support ?
Hardwarehersteller Serverplattform ?
Raidcontroller ?
SAS Festplatten ? Raidversion ?

Ich würde als wichtigsten Punkt feststellen, dass die Datenbank auf einer einzelnen Maschine läuft. Falls das der Fall ist, muss der Fehler am Server liegen.
Dazu wäre es notwendig / vorteilhaft wenn man die Aufteilung der Rollen und mehr zu der jeweiligen Konfiguration wüsste. Definitiv geht es in Richtung Verbindungsprobleme oder evtl. Probleme mit irgendwelchen fehlenden Updates. (MS) Da die Konfiguration und der Stand nicht bekannt ist, ist es wie mit einer Glaskugel - schwierig.
Um die Hardware auszuschliessen würde ich einen anderen Testserver nehmen und die Datensicherung auf andere Hardware spielen. Definitiv separiert vom eigentlichen Netzwerk um Beeinflussung durch andere Sachen im Netzwerk auszuschliessen.
Gruß
XK

Da der Einzelplatz korrekt funktioniert bleibt für mich als Ursache nur ein Fehler am HOST (VM) oder ein Fehler bei der Installation des Serverbetriebssystems übrig. Ich würde den Einzelplatz zum Turbomed Datenbankserver machen und mich dann um eine Neuanschaffung eines Servers bemühen.
Gruß HansW

imb hat geschrieben:Hi,

vielen Dank für die Antworten - ich arbeite sie mal ab

CMD Fenster starten
"ipconfig /all"

Kein 127.0.0.1, nur die "normale" Adresse aus dem Netzwerk

Code: Alles auswählen

Ethernet-Adapter Ethernet:

   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft Hyper-V-Netzwerkadapter
   Physische Adresse . . . . . . . . : 00-15-5D-0A-50-01
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::dd9f:cbc0:7a37:92bf%12(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 172.18.1.11(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.0.0
   Standardgateway . . . . . . . . . : 172.18.1.1
   DHCPv6-IAID . . . . . . . . . . . : 251663709
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-19-8C-30-72-00-15-5D-0A-50-01

   DNS-Server  . . . . . . . . . . . : 172.18.1.10
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Tunneladapter isatap.{85825642-EA45-400D-899E-8E9CE6BB20C3}:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #5
   Physische Adresse . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja

Was ergibt ein "nslookup server" ?

Der DNS Server antwortet mit der passenden IP.

Was ist denn bei Turbomed als Server eingetragen? IP oder Hostname? Falls Hostname: Da Du IPv6 aktiviert hast, wäre die DNS-Abfragereihenfolge: zuerst IPv6 versuchen, wenn Timeout dann erst IPv4 -> somit könntest DU versuchen die IP als TM-Server einzutragen oder aber IPv6 testweise zu deaktivieren.

Grüße

lcer

hofeBY hat geschrieben:OK, Namensauflösung war´s also nicht.

Virtuelle Maschine ist evtl. eine nicht unwichtige Info.

VMware ESXi Server. Version ? Lizensiert mit Support ?
Hardwarehersteller Serverplattform ?
Raidcontroller ?
SAS Festplatten ? Raidversion ?

Hyper-V, Hardware ist supported (es geht um diesen Dell-Server: http://www.vondoczudoc.de/viewtopic.php?f=11&t=6549)
RAID10 aus 4x SAS Platten + 1 Spare.

Da mich mein Bauchgefühl nicht los lässt, dass das Storage-System der aktuelle Engpass ist, werde ich gleich testweise mal eine SSD einbauen und die virtuelle Maschine vom TM-Terminalserver darauf verschieben. Wer weiß, vielleicht gibt es bestimmte DB-Aktionen wo die virtuelle Festplatte (aufgrund des Engpasses) aktuell nicht schnell genug reagiert und TM das als etwas unglücklich undifferenzierte Meldung an die Oberfläche bringt.

PCI hat geschrieben:Ich würde als wichtigsten Punkt feststellen, dass die Datenbank auf einer einzelnen Maschine läuft. Falls das der Fall ist, muss der Fehler am Server liegen.
Dazu wäre es notwendig / vorteilhaft wenn man die Aufteilung der Rollen und mehr zu der jeweiligen Konfiguration wüsste. Definitiv geht es in Richtung Verbindungsprobleme oder evtl. Probleme mit irgendwelchen fehlenden Updates. (MS) Da die Konfiguration und der Stand nicht bekannt ist, ist es wie mit einer Glaskugel - schwierig.
Um die Hardware auszuschliessen würde ich einen anderen Testserver nehmen und die Datensicherung auf andere Hardware spielen. Definitiv separiert vom eigentlichen Netzwerk um Beeinflussung durch andere Sachen im Netzwerk auszuschliessen.
Gruß
XK

Ja, die DB lief auf einem anderen PC einen Tag fehlerfrei (es wurde quasi "lesend" in TM als Überbrückungslösung gearbeitet) und die Konsistenzprüfung läuft dort erfolgreich.

Auf dem Server ist die Konsistenzprüfung auch schon mal erfolgreich durchgelaufen, gestern kam es aber zum Fehler. Auch im normalen "Durch Karteikarten blättern" ist der Fehler aufgetreten. Scheint also etwas zufällig zu sein, aber wurde wieder beobachtet.

Die neue VM ist ein frisch installierter Win Server 2016, Standardrollen (DC ist eine eigene VM) + TM + Virenscanner (Avira). Die aktuellen Windows-Updates sind eingespielt. Ich werde die VM nachher mal vom Netzwerk abschotten, einen anderen Server wo ich die VM kurz rüberschieben könnte, hab ich gerade nicht zur Hand.

Achja, memtest86 hat keine Fehler ergeben, der RAM scheint es also nicht zu sein.

lcer hat geschrieben:
imb hat geschrieben:Hi,

vielen Dank für die Antworten - ich arbeite sie mal ab

CMD Fenster starten
"ipconfig /all"
Kein 127.0.0.1, nur die "normale" Adresse aus dem Netzwerk
Code: Alles auswählen
Ethernet-Adapter Ethernet:

   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft Hyper-V-Netzwerkadapter
   Physische Adresse . . . . . . . . : 00-15-5D-0A-50-01
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::dd9f:cbc0:7a37:92bf%12(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 172.18.1.11(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.0.0
   Standardgateway . . . . . . . . . : 172.18.1.1
   DHCPv6-IAID . . . . . . . . . . . : 251663709
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-19-8C-30-72-00-15-5D-0A-50-01

   DNS-Server  . . . . . . . . . . . : 172.18.1.10
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Tunneladapter isatap.{85825642-EA45-400D-899E-8E9CE6BB20C3}:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #5
   Physische Adresse . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
Was ergibt ein "nslookup server" ?
Der DNS Server antwortet mit der passenden IP.
Was ist denn bei Turbomed als Server eingetragen? IP oder Hostname? Falls Hostname: Da Du IPv6 aktiviert hast, wäre die DNS-Abfragereihenfolge: zuerst IPv6 versuchen, wenn Timeout dann erst IPv4 -> somit könntest DU versuchen die IP als TM-Server einzutragen oder aber IPv6 testweise zu deaktivieren.

Grüße

lcer

Bei TM ist der Hostname als Server eingetragen. Ich werde IPv6 gleich mal abschalten, brauchen wir eh nicht.

Vielen Dank für die rege Beteiligung!

VonDoczuDoc.de

Absturz Runtime-Error

Absturz Runtime-Error

Re: Absturz Runtime-Error

Re: Absturz Runtime-Error

Re: Absturz Runtime-Error

Re: Absturz Runtime-Error

Re: Absturz Runtime-Error

Re: Absturz Runtime-Error

Re: Absturz Runtime-Error

Re: Absturz Runtime-Error

Re: Absturz Runtime-Error

Re: Absturz Runtime-Error

Re: Absturz Runtime-Error

Re: Absturz Runtime-Error

Re: Absturz Runtime-Error

Re: Absturz Runtime-Error

Re: Absturz Runtime-Error

Re: Absturz Runtime-Error

Re: Absturz Runtime-Error

Re: Absturz Runtime-Error

Re: Absturz Runtime-Error