[Gelöst]Nav_Datensicherung "Der Fehler (1185 im Modul 1

Navision Version:

Navision DB 2.6, technisch konvertiert auf Navision 3.7 (Native DB)



Problem Beschreibung:

Nach einem Stromausfall läuft im Navision keine interne Datensicherung mehr. Die Datensicherung wird mit der Fehlermeldung aus Anhang 1 abgebrochen.
Eigentlich ein Zeichen dafür, dass der Platz in der Datenbank knapp wird und eine Erweiterung selbiger sich als nützlich erweisen würde. Aber die Datenbank ist nur zu 60% ausgelastet.
Nichts desto trotz haben wir versucht, die Datenbank-Datei zu erweitern. Ohne Erfolg, die Fehlermeldung erscheint immer wieder.
Bei der "Datenbank prüfen"-Funktion tritt derselbe Fehler auf.

Daraufhin haben wir die Funktion zur Prüfung einzelner Tabellen aufgerufen, um den Fehler zu lokalisieren. Die Prüfung hat ergeben, dass der Fehler in der Tabelle 32 ("Artikelposten") auftritt.
Beim Prüfen der Schlüssel dieser Tabelle tritt die Fehlermeldung aus Anhang 2 auf.

Um den Fehler zu beheben, haben wir versucht, die komplette Tabelle in eine neu angelegte Tabelle zu kopieren. Den Kopiervorgang jedes einzelnen Datensatzes haben wir mit COMMIT bestätigt, um die fehlerhaften Datensätze lokalisieren zu können. Wir konnten so feststellen, dass es sich bei dem Fehler um 13 zusammenhängende Datensätze handelt.

Die betroffenen Datensätze können weder per Filter, noch per Codeunit angezeigt oder gelöscht werden. Beim Scrollen durch die Datensätze tritt der Fehler aus Anhang 3 ebenfalls wieder auf.


Wir benötigen somit ein Programm, welches in der Lage ist, die Datensätze direkt aus der Native DB zu löschen bzw. ein Recovery Programm, mit dem man den fehlerhaften Bereich ausschließen kann.

Über einen Lösungsvorschlag würden wir uns sehr freuen.

Vielen Dank

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Zuletzt geändert von Irchik am 16. Oktober 2007 15:15, insgesamt 1-mal geändert.

Ich behaupte mal, ihr habt da jetzt ein großes Problem, denn meine Datenbank sagt folgendes:

Interner Fehler 1185 in Modul 19
Modul 19 = Datenbank-Fehler (siehe auch Modul 34)
Fehlercode: 1246369
Beschreibung: #Err_DB_BlockNotOwnedByTable
Aktueller Status: In Bearbeitung
Auswirkung: Datenbank ist zerstört

Betroffene Software-Version(en):
NAVISION Financials 2.00.D deutsch
NAVISION Financials 2.60.A deutsch

Vorgänge, die zum Fehler führen (können):
Veränderung in einem Report. Der Report schreibt Daten in eine Tabelle.
Bei der Überprüfung der Tabelle über Datenbankinformationen ist die Fehlermeldung aufgetreten
Am Report wurden nur Veränderung bezüglich dem Layout durchgeführt,
es wurden keine Schreiboperationen auf die Tabelle verändert.
(P.S.: zu diesem Zeitpunkt waren noch 50% der DB frei!)
oder:
Folgende Fehlermeldung wird bei einer unserer Entwicklungsdatenbanken ausgegeben.
"Andere Aktivitäten haben den freien Platz überschrieben, der den Speicherbereich enthielt, den diese Aktivität....."
Führt man die Datenbank - Prüfroutine auf den Primärschlüssel der angegebenen Tabelle aus, wird diese Meldung angezeigt:
"Es ist ein Fehler in der Datenbankstruktur aufgetreten. Der Fehler (1185 in Modul 19)
wurde eventuell von dem Computer oder einem Programm verursacht. [...]
Eine Sicherung der Datenbank (auch wenn die Datenbank mit READONLY geöffnet wird) ist nicht mehr möglich.
Das Objekt läßt sich auch im Design - Modus nicht bearbeiten. Die Datenbank wurde nicht erweitert.
oder:
Während des Verbuchens einer Zahlung erscheint die Meldung
"Andere Aktivitäten haben den freien Platz überschrieben, der den Speicherberech enthielt, den diese Aktivität ..."
Beim Prüfen der Sekundärschlüssel tritt dann in der Tabelle 39 der Fehler 1185 in Modul 19 auf.

(Mögliche) Ursache/n:
Vermutlich wurde versucht, einen Block zu lesen, der nicht mehr zur gewünschten Tabelle führt.
Gewöhnlich tritt dieser Fehler dann auf, wenn eine Transaktion
durch das Festplattensubsystem fehlerhaft durchgeführt wurde.

(Mögliche) Lösung/en:
Bitte lesen Sie die letzte Datensicherung ein.
Am Besten auf einer neuen Platte, da es nicht auszuschließen ist,
daß der Controller oder der Treiber des Controllers einen Fehler hat.

Wenn das Problem nicht gerade der Primärschlüssel war, sollte es durch deaktivieren des Schlüssels, speichern, wieder aktivieren des schlüssels und wieder speichern zu beheben sein.
Wenn es jedoch der Primärschlüssel ist, hast du ein echtes Problem.
Ich würde evtl mal folgendes versuchen:
einen neuen Primärschlüssel einfügen also in der ersten Zeile der Schlüsseldefinitionen F3 drücken, der aus mehreren Feldern besteht, und irgendwo zwischendrin das Feld lfdNr. beinhaltet,
dann den alten Primärschlüssel löschen und die Tabelle speichern.
Wenn das erfolgreich war, den Primärschlüssel wieder auf die lfdNr. zurechtstutzen und erneut speichern.
Während dieser Arbeit sollte KEINER, auch kein NAS sonst in der Datenbank sein und auch alle Timeraktivitäten deines aktiven Clients, die evtl auf diese Tabelle zugreifen deaktiviert sein.
Am besten Serverdienst anhalten und mit lokalem Client die Datenbank öffnen.

Die Chance ist zwar gering, aber vielleicht klappt es ja.

Hi,

@Timo: Danke für die Fehlerbeschreibung allerdings ist der Inhalt nicht so schön...

@Michael: Der Primärschlüssel ist defekt. Also probier ich mal einen neuen Primärschlüssel anzulegen. Vielen Dank für den Vorschlag.

Ich bin gespannt...

Es kam leider zu keiner Lösung des Problems
Ich habe folgendes versucht:
1. Neuen Primärschlüssel (Artikelnr., Lfd. Nr., Postenart) angelegt, damit Lfd. Nr. zwischendrin ist
2. Alten Primärschlüssel gelöscht
3. Gespeichert.

Der selbe Fehler wie aus Bild Jpg1 s. Anhang.

Hast du - wie von Michael empfohlen - lokal auf die Datenbank zugegriffen?
Also den Serverdienst gestoppt und die Datenbank lokal geöffnet?

Falls dem so war, dann bleibt wohl wirklich nur der Griff nach der letzten Datensicherung.

Gut, eine Alternative gibt es noch, aber die ist extrem teuer:
Das Headquarter in Dänemark hat ein Tool, mit dem versucht werden kann, die Datenbank zu reparieren.
Eine Erfolgsgarantie gibt es dafür natürlich nicht.
Solltet ihr also keine (funktionierende, fehlerfreie) Datensicherung zur Hand haben, so musst du dich mit diesem Problem an euren Partnermanager bei Microsoft wenden.
(Laut deinem Profil seid ihr ja Microsoft Partner, anderenfalls wendet ihr euch an euren betreuenden MBSP.)

Ja, ich habe lokal auf die Datenbank zugegriffen. Wir haben uns vom Server die Datenbankdateien runterkopiert, damit wir eine Testumgebung haben, weil die Datenbank weiterhin in Betrieb ist. Datensicherungen sind natürlich vorhanden, aber die sind ja jetzt schon wieder sehr "alt" nach den vielen Tagen. Das Problem, dass keine Datensicherung mehr erstellt werden kann, wurde erst spät bemerkt. Wenn uns das gleich am nächsten Tag aufgefallen wäre, hätten wir ein Backup Recovery in eine neue Datenbank gemacht und es könnte sofort wieder mit den Daten vom vorabend weitergearbeitet werden... Ich melde mich wieder wenn es Neuigkeiten gibt.
Danke für eure Hilfe!

Hallo an alle,

wir haben viele Sachen ausprobiert, aber nichts hat uns geholfen. Die Datenbank ist nicht reparierbar. Uns bleibt nur eine Möglickeit, eine neue Datenbank anzulegen und die alte Datensicherung zu importieren. Das Problem wird aber damit noch nicht gelöst, weil noch ein Abgleich zu den aktuellen Daten erfolgen muss. Die Differenz zwischen der alten Datensicherung und den aktuellen Daten beträgt ca. 30 Tage.
Das Kopieren (Codeunit, Dataports) ist richtig zeitaufwendig. Weil wir den Betrieb nicht lahm legen können und die DB 30GB (ca. 1,7 Millionen Artikelposten, 250000 Artikel und s.w. ) groß ist, brauchen wir eine schnelle automatisierte Lösung die Tabellen komplett mit Daten kopiert (ich meine nicht Zeilenweise). Wenn jemanden schon so eine Lösung bekannt ist oder andere Ideen hat, bitten wir um Hilfe.

Der Algorythmus zum Ableich der Daten würde uns auch sehr helfen.

Danke.

@Timo
das ReparaturTool ist extrem teuer.

wir hatten da ein ähnlichs Problem, (eine Version der Datenbank war nícht korrekt freigegeben worden) ansonsten gleiche bzw. ähnliche Symptome.
zufälligerweise sind wir dann an MBS Österreich verwiesen worden. Da war die Reparatur quasi kostenlos.

@Thomas(tba), danke. Kannst du dich vielleicht errinern, wie diese ReparaturTool heißt ?

Wir haben eine SupportAnfrage an Microsoft erstellt. Leider sagen sie uns, dass es keine Möglichkeit gibt die DB zu reparieren.
Sie empfehlen uns eine neue DB anlegen und die daten manuell zu kopieren (alles, außer fehlerhaften Bereich). Es gibt einen riesigen Nachteil - das dauert viel zu lange

Hallo Irchik,

es dürfte sich dabei um das Reparaturtool C/DART handeln.

Leider ist dies, wie bereits weiter oben erwähnt, nicht frei verfügbar

MfG
Christian

@cmueller, Danke für dein Tipp.

Kann mir jemand sagen wie viel das ReparaturTool kosten und wer ist der Ansprechpartner.

Kann mir jemand sagen wie viel das ReparaturTool kosten und wer ist der Ansprechpartner.

Das Tool ist nicht verkäuflich, sondern wird ausschließlich von Microsoft verwendet, um (gegen eine entsprechend hohe Gebühr) zu versuchen die eingesendete Datenbank zu reparieren.
Wende dich diesbezüglich am besten direkt an euren Partner-Account-Manager bei Microsoft.

Ich weiss nicht wie aufwändig das ist, aber hast du mal daran gedacht die native datenbank (inkl. Fehler) in eine SQL - Datenbank zu konvertieren?
(sofern das mit den Fehlern möglich ist?) und dann sozusagen von aussen (per SQL-Befehle) auf die fehlerhaften Daten zuzugreifen, dann zu reparieren und wieder zurückzuschreiben?

Wie gesagt, alles höchst nebulös...aber ansonsten würde mir auch nichts dazu einfallen...aber trotz fehler funktioniert eure datenbank ja wohl, solange niemand auf diesen block daten zugreifen muss.

Wir hatten auch mal einen Datensatz der sich so seltsam verhielt. Wenn man drübergescrollt ist, gab es auch so eine Fehlermeldung..aber ich glaube wir haben das mit einem Report lösen können und den datensatz noch löschen können.

@Pegasus
Das haben wir als erstes gedacht, die native DB in eine SQL – DB zu konvertieren. Dafür brauchen wir aber eine Datensicherung, die wir nicht erstellen können.



Danke für deine Hilfe.