[gelöst]fbk in SQL-Datenbank einlesen

[rainergaiss]

Hallo zusammen,

ich habe ein Problem beim Einlesen einer fbk-Sicherung in eine SQL-Datenbank. Diese Datenbank soll von uns "bereinigt" werden. Sie ist ziemlich "dirty", d.h. es gibt etliche Fehler beim Kompilieren. Nun wird diese Sicherung zwar eingelesen und es werden auch die Schlüssel aufgebaut, aber dann gibt es beim Einlesen in SQL noch eine Phase, die es in der nativen Datenbank nicht gibt, ich nehme an, eine Art Kompilierung. An dieser Stelle wird dann das Einlesen der fbk-Datei mit einer Fehlermeldung (Feld gibt es nicht in einer Tabelle) abgebrochen, ohne dass dann danach noch irgendetwas in der Datenbank steht.

Wer kann mir sagen, was da genau in der letzten Einlesungsphase geschieht und ob ich die irgendwie um- oder übergehen kann?

Wenn ich die fbk-Datei in eine native Datenbank einlese, habe ich diese Probleme nicht, allerdings habe ich einen Arbeitsgang mehr, weil ich die bereinigte Datenbank ja doch wieder in SQL einlesen muss. Die Datenbank hat eine Größe von rund 60GB.

Im Voraus danke für eure Tipps!

Rainer

Zuletzt geändert von rainergaiss am 5. September 2012 09:03, insgesamt 1-mal geändert.

Wenn du zunächst versuchst, die Objekte in einer nativen Datenbank zu bereinigen, oder aus der FBK zunächst nur die Objekte versuchst einzulesen, damit du Sie bereinigen kannst?

Gruß, Fiddi

Ist die fbk aus einer nativen DB heraus erstellt worden?
Dann ist die nicht "mal so eben" auf SQL hochzuziehen; das Thema ist MS eine ganze Schulungsunterlage wert:
Kurs 80298 (engl.)
Außerdem:
Workaround: Migration von nativ auf SQL Server mit NAV 2009 R 2 Build >= 32942
Migrate from Native to SQL Server : dates before 1753/01/01

Das habe ich ja geschrieben, dass das geht. Es dauert halt alles dann etwas länger, weil ich die bereinigte Datenbank doch wieder ins SQL einlesen muss. Bei 60 GB sind das schon "ein paar Minuten".

Meine Vorgehensweise wäre jetzt:
1. Objekte aus alter DB exportieren
2. Objekte in Nativer DB- bereinigen entweder mit denen aus der FBK oder denen aus 1.
3. neue SQL-DB aufbauen
4. bereinigte Objekte einspielen
5. FBK ohne Objekte einspielen.

Gruß, Fiddi

Ist die fbk aus einer nativen DB heraus erstellt worden?

Ja, aber nicht von mir.

Migrate from Native to SQL Server : dates before 1753/01/01[/url]

Das kenne ich alles, aber die Daten sind "bereit" für SQL. Es geht mir darum, dass er in der (wirklich nötigen?) Compilierphase am Ende rausfliegt, weil er einige nicht compilierbare Objekte hat, die ich aber gerade bereinigen möchte und auch würde, wenn er mich das Ganze erst einmal einlesen ließe.

Meine Vorgehensweise wäre jetzt:
1. Objekte aus Alter DB exportieren
2. Objekte Bereinigen
3. neue SQL-DB aufbauen
4. bereinigte Objekte einspielen
5. FBK ohne Objekte einspielen.

Gruß, Fiddi

So hätte ich es auch gemacht. Da ich aber mit einer fbk beginne, muss ich trotzdem erst die Native aufbauen (zum Bereinigen der Objekte) UND dann die SQL. Muss der denn beim Einlesen in SQL unbedingt kompilieren?

Gruß, Rainer

Muss der denn beim Einlesen in SQL unbedingt kompilieren?

Ja, damit der RTC funktioniert.

Hallo Rainer,

wie wärs denn, wenn du zuerst die Objekte aus der fbk in eine neue SQL-DB einliest, die Objekte dann "bereinigst", und dann die fbk ohne Objekte einliest?

Gruß
Josef

wie wärs denn, wenn du zuerst die Objekte aus der fbk in eine neue SQL-DB einliest, die Objekte dann "bereinigst"

es ist ja gerade das Problem, dass das nicht funktioniert

Gruß, Fiddi

[...] An dieser Stelle wird dann das Einlesen der fbk-Datei mit einer Fehlermeldung (Feld gibt es nicht in einer Tabelle) abgebrochen, ohne dass dann danach noch irgendetwas in der Datenbank steht. [...]

Ich glaube, dass genau auf dieses Phänomen der Fokus gelegt werden soll.

Meine Vermutung (weil ich selber vor Kurzem damit zu kämpfen hatte):
Feldnummer 27 ist in der Tabelle 'Objektmetadata' nicht definiert.

Meine Vermutung (weil ich selber vor Kurzem damit zu kämpfen hatte):

Leider nein, es war eine ganz normale Tabelle, wie gesagt, das Ding ist "dirty".

Gruß

Rainer

Meine Vermutung (weil ich selber vor Kurzem damit zu kämpfen hatte):

Leider nein, es war eine ganz normale Tabelle, wie gesagt, das Ding ist "dirty".

Hast du zufällig den exakten Wortlaut der Fehlermeldung?
Ich glaube, das könnte uns ggfls. weiterhelfen, um dir weiterzuhelfen

Hallo Rainer,

hast du dir Natalie's Link genauer angesehen (http://blogs.msdn.com/b/german_nav_deve ... 32942.aspx)?

Wenn es der Prozess ist, in dem die Objekte für den NAV Server erstellt werden, also C# generiert und in die Tabelle Object Metadata geschrieben wird, dann kannst du durch abwählen der Option "Für Dynamics NAV Server aktivieren" diesen Schritt zunächst ausschalten.

Ansonsten ist der genaue Wortlaut der Meldung der Schlüssel

Wenn es der Prozess ist, in dem die Objekte für den NAV Server erstellt werden, also C# generiert und in die Tabelle Object Metadata geschrieben wird, dann kannst du durch abwählen der Option "Für Dynamics NAV Server aktivieren" diesen Schritt zunächst ausschalten.

Hallo Carsten,

vielen Dank. Genau das habe ich gerade noch probiert, bringt aber auch nichts, das heißt der Fehler muss wohl doch schon in einer früheren Phase kommen. Da man bei dieser Datenbank mit so vielen Folgefehlern rechnen muss, wenn man erst einmal nur einen behebt, gehe ich jetzt doch erst einmal den Weg über die native Datenbank.

Danke auch den anderen für die Hilfe.

Rainer