Fehler bei EODB Datenanpassung nach Update auf V14.1

[#1]

Hallo,

erstmal ein frohes und gesundes neues Jahr wünsche ich der Community.

Jetz zum Problem, habe gestern auf die Version 14.1 aktualisiert (Client/Server Umgebung, Windows Server 2019).

Soweit lief alles glatt bis das die Datenanpassung der EODB nicht funktionierte. Zuerst während der parallel Installation mit Fehler, eine erneute Datenanpassung nachdem alle PC aktualisiert waren meldte keinen Feehle mehr.

Wurde danach der Arbeitsplatz gestartet, wird eine Datenanpassung der EODB verlangt. Diese schlägt fehl, so als wenn das Laufwerk oder ein anderer Teil der Hardware fehlerhaft wäre. Das ist aber nicht der Fall.

Bei der Untersuchung war aufgefallen, dass die DB DATEV/DATEN/ZMSD/STANDARD/META/MANDANT nicht an den Server gebunden ist. Habe dann versucht die entsprechend der Anweisung aus 1007176 zu beheben. Leider hilft das Dokument nicht, da die hier angegebenen Konfig-Verzeichnisse nicht vorhanden sind.

Hier ein Auszug aus der Logdatei.

Wäre gut wenn jemand eine Idee hat, weil durch den Fehler ist das Büro erstmal kaltgestellt.

Mit freundlichen Grüß

D. Sigulla

[#2]

... nur eine Idee:

... wenn es um den Auswertungspool geht, würde ich selbst in der zweiten Instanz des SQL-Servers nachsehen.

Vielleicht auf einem anderen Server oder einem Arbeitsplatz

... wie gesagt, ohne Gewehr und ohne Gewähr 😉

[#3]

Hallo Herr Vogtsburger,

was meinen Sie mit 2. Instanz? In der SQL Server Administration sehe ich nur einen Server.

Leider schein es sich aber auch nicht nur um den Auswertungspool zu handeln, z.B. Rechnungsschreibung geht nicht.

Im Moment ist die Anweisung nur lesend auf die DB zuzugreifen und keine Ändeurng vorzunehmen, solange das Problem nihct gelöst ist.

Trotzdem vielen Dank für den Hinweis

Gruß

D. Sigulla

[#4]

Hallo,

sehr eigenartiges Problem. Ich würde mal über Start > Ausführen, das Tool eodbconfig starten. Dann auf der linken Seite alle 3 Button verwenden und die Pfade prüfen. Bei Unstimmigkeiten die Einstellungen in der Datenumgebung vornehmen. Eventuell gibt es auch mehrere Pfade. Dann den richtigen auswählen. Entweder er möchte dann die DBs gleich anpassen, oder Sie machen die Anpassung dann über den Installationsmanager erneut. Könnte eventuell helfen.

Gruß Blablax

[#5]

Danke für den Hinweis auf eodbconfig, da habe ich schon gemacht, da ist alles korrekt.

Wie Sie schon sagen, ein seltsames Verhalten. Ich kann mir das nur damit erklären, dass die Datenanpassung parallel zu der Installation der Clients etwas durcheinander gebracht hat. Bisher hatte ich aber nochnie solch ein Problem.

Gruß

D. Sigulla

[#6]

Dann würde ich die Datenbank ASPOOL.mdf aus der Sicherung (vor dem Update) zurückholen. Vorher den Ist Stand (also defekte DB/Ordner) sichern. Dann die Anpassung erneut anstoßen.

Hier wird auch bei Fehler die ASPOOL entsprechend kopiert:

https://www.datev.de/dnlexom/client/app/index.html#/document/1007176?hitMarkTerms%5B%5D=rw40_1007176&hitMarkTerms%5B%5D=aspool.mdf

https://www.datev.de/dnlexom/client/app/index.html#/document/1011840?hitMarkTerms%5B%5D=rw40_1011840&hitMarkTerms%5B%5D=aspool.mdf

Da hier so pragmatisch vorgegangen wird, denke ich, die DB ist nicht ganz so sensibel. Trotzdem den defekten Stand sichern.

Gruß blablax

[#7]

---

@asiguld schrieb:

Bei der Untersuchung war aufgefallen, dass die DB DATEV/DATEN/ZMSD/STANDARD/META/MANDANT nicht an den Server gebunden ist.

---

Dann würde mich mal interessieren, was die tägliche SQL Datenbankprüfung zu der Datenbank bis zum Update gesagt hat. Das Ergebnis kann man sich auch per Mail schicken lassen. 

Microsoft SQL Server: Ergebnisse der Datenbankprüfung anzeigen

E-Mail-Benachrichtigung einrichten, um Ergebnisse der Datenbankprüfung zu erhalten

Sonst bin ich bei @blablax. Die SQL Datenbank aus der Sicherung zurückholen und ersetzen und dann nochmal schauen. 

---

@asiguld schrieb:

Ich kann mir das nur damit erklären, dass die Datenanpassung parallel zu der Installation der Clients etwas durcheinander gebracht hat.

---

Nein, hat damit nichts zu tun. Das mache ich genauso: TS1 macht die Datenanpassung während TS02 bis TS05 die Installation machen. Das hatte ich aber auch schon einmal mit der REWE Datenbank, die plötzlich nicht angepasst werden konnte. Warum auch immer.   

[#8]

https://www.datev.de/dnlexom/client/app/index.html#/document/1044364?hitMarkTerms%5B%5D=rw40_1044364&hitMarkTerms%5B%5D=EODB%2520Datenanpassung%2520fehler

[#9]

Hallo zusammen,

bitte prüfen Sie in diesen Fällen unverzüglich Ihre Datenbanken. Der Fehler DB60024 kann im Zuge eines technischen Defekts der Datenbank auftreten.

Weitere Informationen dazu finden Sie im Hilfe-Center:

DB60024 beim Arbeiten mit DATEV-Programmen 

[#10]

Hallo @Andreas_Huxhagen ,

dieser Fehler hätte aber doch auch schon vor dem Update bei der direkten Prüfung der Datenbanken oder beim SQL-Prüf- und Sicherungslauf (Online-Sicherung) auffallen müssen, oder ?

Nachtrag:

... übrigens, mich hatte gestern bei der Kontrolle der "Ergebnisdatei der Datenbankenprüfungen" irritiert, dass die genannte Datenbank DATEV/DATEN/ZMSD/STANDARD/META/MANDANT bei mir nicht auftaucht, sondern 'nur' 3 andere aus dieser 'ZMSD-Meta-Ecke' (MITARBEI, ADRESSAT, INDADR).

(wir setzen EO Comfort ein)

[#11]

Hallo vogtsburger!

richtig.

Die Datenbank hätte schon lange vor dem Update auffallen müssen: Ein eingerichteter Prüf- und Sicherungslauf hätte bei einem Defekt der Datenbank DATEV/DATEN/ZMSD/STANDARD/META/MANDANT gewarnt. www.datev.de/info-db/1013210 

Am Tag des Updates - so vermute ich - hing die (korrupte) Datenbank nicht mehr am SQL-Server.

Grüße aus Nürnberg

Christian Tölle

IT-Systemplattform

DATEV eG

[#12 · Accepted solution]

Hallo,

ich bin Ihnen noch eine Lösung schuldig.

Erstmal vielen Dank für Ihre Beteiligung. Der Hinweis, dass die DB schon vorher eine Fehler hatte kann ich nihct bestätigen. Die DB wird täglioch geprüft und zwar jeweils vor dem Sicherungslauf. Da ist nichts aufgefallen.

Also die Ursache ist unklar aber die Lösung war einfach.

Ich konnte auf dem Server die Konfigverzeichnisse nicht finden, da aufdem Server nicht alle Programe installiert sind. Nachdem ich dann mit Unterstützung von DATEV die frische DB-Dateien von einem Kleint geholt hatte, lief die Datenanpassung duch und alles war wieder i.O..

Wir hatten auch keinen Datenverlust, da in der betroffenen Datei individuelle Mandantendaten abgelegt werden wir diese aber nicht verwenden.

Vielen Dank nochmal

Gruß

D. Sigulla

[#13]

... klingt, als ob es sich hier um einen lokalen Datenbestand gehandelt hat.

Bei uns ist z.B. kein Anwendungsprogramm auf dem Server installiert (Steuern, Rewe, Lohn etc.). Trotzdem befinden sich alle SQL-Datenbanken auf dem Fileserver. 

.. aber egal, das Problem ist gelöst ... das ist das Wichtigste ... 

[#14]

In diesem Zusammenhang würde mich interessieren, ob es "normal" ist, daß die Update- bedingte Datenanpassung der EODB länger dauert, als sie Anpassung aller anderen Anwendungen incl. ReWe mit 40 GB?
Fehlerhafte Datenbanken wurden noch nie "gemeldet" und es gibt keinerlei Fehler aus den Anwendungen.

[#15]

@martinkolberg ,

bei uns dauert die Datenanpassung der EODB (EO Comfort) jedenfalls nicht länger als die Datenanpassung von Kanzlei-REWE, sondern ganz grob nur etwa halb so lang.

Stammen die Zeitangaben aus dem Logbuch der Datenanpassungen ?

Ich erinnere mich an Logbücher, die noch wesentlich detaillierter sämtliche Schritte während der Programminstallationen und der Datenanpassungen protokollieren.

(edit: z.B. im Pfad ...\DTTrafo\Tasks\...  die Dateien ...DataAdaptationManager.log)

Und soweit ich mich erinnere, kann es auch passieren, dass eine Datenanpassung mehrere Anläufe benötigt, um eine SQL-Datenbank umzusetzen.

Das wäre aus meiner Sicht eine mögliche Erklärung, warum eine Datenanpassungen mal länger dauern kann als erwartet bzw. länger als sonst.

... werde mal bei nächster Gelegenheit nach den entsprechenden 'Trafo-Aktionen' in den gesammelten Logbüchern suchen ...

... das Thema interessiert mich nämlich auch.

Vielleicht kündigen sich Fehler in SQL-Datenbanken ja schon frühzeitig in diesen Logdateien an.