[Gelöst] Alle Secondary Keys deaktiviert

Guten Tag miteinander

Seit Wochen erhalte ich sporadisch eine auf NAV6 konvertierte Datenbank mit NAV5-Objekten und alles lief wie erwartet. Als ich die letzte .fbk in eine neue DB eingelesen habe, wurderte ich mich bereits am Ende vom Import, dass die Schlüssel nicht aktualisiert worden sind. Und siehe da; auf sämtlichen Tabellen sind alle Secondary Keys zwar noch vorhanden - aber deaktiviert. Einzig die PK der Tabellen sind unverändert aktiv. Modify-Date & -Time der Tabellen sind im Originalzustand und ein Compare alter und neuer Objekte (als .txt-Export) ergab einzig den Unterschied BackupKey=YES. Dachte erst, dass die DB zu wenig Platz aufweist und hab diese voller Zuversicht erweitert, den Import wiederholt aber leider ohne Erfolg bzw. mit gleichem Fehler. Die Orignial-DB, von der das .fbk stammt, läuft im Übrigen tadellos und weist auch noch genügend Platz auf.

Hat jemand eine Ahnung, was und wie man so etwas bewerkstelligen kann bzw. sowas passiert und vor allem wieder rückgängig machen kann?

Viele Grüsse und Danke für eventuelle Tipps.

Zuletzt geändert von blunx am 26. März 2010 12:12, insgesamt 1-mal geändert.

Hallo blunx,

ich kann mich dunkel daran erinnern, dass ich das Problem schon einmal auf einer 4er native DB hatte...
Du kannst zwei Dinge probieren. Beim neuen Start Import Datensicherung (sofern die vorherige abgebrochen ist) setzt er mit dem Import fort und baut dann auch die Keys auf.
Alternativ kannst Du alle Tabellen aus der Original DB als FOB exportieren und in Deine Datenbank importieren - dann sollte er die Keys - sofern sie im Original aktiv sind - auch aufbauen.

gruß
42

Hast du den abgebrochenenen Import wiederaufgenommen ( das ging bisher) oder komplett neu eingelesen? Ich hatte das heute auch mit SP1 Client, nach Wiederaufnahme des Imports nach der Erweiterung einer zu kleinen DB. Erst eine komplette Neueinlesung in eine leere und ausreichend große DB hat die Keys dann aktiviert.

Hallo 42,
hallo Kowa

Danke für Eure Tipps. Dachte erst auch, dass der Import abbricht (weil DB zu klein oder so) und deshalb keine Keys generiert werden. Habe es bereits vorgängig mit größeren DBs probiert. Die DB habe ich jeweils komplett neu erstellt (mit mehr als der doppelten von der ursprünglichen Größe). Es erscheint nach dem Import auch jeweils die Meldung "Datenimport erfolgreich abgeschlossen".

Nur die Objekte als .fob zu übernehmen nützt mir leider nichts; denn ich benötige auch die Daten der Native-DB. Ausserdem würde mich grundsätzlich interessieren, was der Grund für dieses Übel ist?!

Viele Grüsse
Leo

42 meinte durch das einspielen der FOBs den Aufbau der Schlüssel zu erreichen.

Gruß, Fiddi

Guten Tag

Habe nun folgendes versucht, was zwar nicht opportun ist, aber so problemlos funktioniert hat, dass ich um Eure Meinung fragen möchte.

1. Neue NAV6 DB [1] erstellt,
2. Original-Objekte von NAV6 (Cronus) in NAV6 DB [1] importiert,
3. Daten von bestehender NAV6 DB [0] (mit NAV5 Objekte, wo Secondary Keys deaktiviert sind) in die neue NAV6 DB [1] importiert
4. Angepasste NAV5-Objekte (von der NAV6 DB [0]) in neue NAV6 DB [1] importiert

Secondary Keys sind wieder da und die Datenbank ist auch gleichzeitig technisch auf NAV6 aktualisiert (abgesehen von den angepassten Reports). Daten scheinen auch alle vorhanden zu sein. Wo könnten noch Probleme auftreten? Und die Frage bleibt; warum sind die Secondary Keys in der NAV6 DB [0] nicht vorhanden?

Bin auf Euer Feedback gespannt und bedanke mich für Euren Input.

Viele Grüsse
Leo

42 meinte durch das einspielen der FOBs den Aufbau der Schlüssel zu erreichen.

Hay fiddi,

Ja, danke für den Hinweis. Habe es probiert aber leider ohne positives Resultat. Die FOBs wurden erfolgreich eingelesen - haben aber betreffend den nicht vorhandenen Secondary Keys nichts geändert.

Viele Grüsse
Leo

Hallo blunx,

Dein Lösungsansatz bereitet mir ehrlich gesagt Bauchschmerzen. Durch diese Vorgehensweise hast Du auf Tabellenebene - und die ist erst mal die kritische - einen Mischstand aus NAV 5/2009 produziert. Du hast evtl. einige Tabellen mit Stand NAV 2009 im System (z.b. neue Felder/Keys) und dazu dann auch einige "reine" NAV 5 Objekte in der Datenbank - ob das auf Dauer sauber läuft, dafür möchte ich meine Hand nicht ins Feuer legen. Vor allem da ich nicht weiß zu welchem Zweck Du diese Datenbank benötigst.
Mich wundert nur, dass Du über den Import der Nav 5 Tabellenobjekte nicht den Aufbau der Keys provozieren konntest. (an Replace All gedacht?)

Wenn ich Dich richtig verstanden habe, hast Du diese Datenbank (technisch NAV 6, Businesslogik NAV 5) doch schon mehrfach als FBK übernommen. Warum erstellst Du keine neue Datensicherung und importierst diese in eine neue Datenbank. (Das Zeitproblem bei solchen Spielchen ist mir durchaus bewusst)
Wie groß ist denn die Original-FDB? Mit einer externen Platte lässt sich die doch viel einfacher transferieren.

Edit: Was passiert denn wenn Du eine Tabelle im Design Modus öffnest und die Keys wieder aktivierst? Klappt das denn noch?

Gruß
42

Guten Tag

Habe die .fdb abgeholt, alle vorhandnen Keys erfolgreich geprüft und folgendes probiert:

1) .txt-Export aller Objekte scheiterte mit Fehlermeldung "Keine Berechtigung zum Lesen von 'irgendeiner' Tabelle".
2) .fob-Export aller Objekte war erfolgreich.
3) .fob-Datei in DB ohne Keys eingelesen = Schlüssen waren wieder vorhanden.
4) .fbk der DB erstellt und wieder in neue DB erfolgreich eingelesen (mit SK).

Somit war der Tipp von 42 doch hilfreich; einzig dass ich nicht nur alle Tabellen-Objekte (sondern alle Objekte) als .fob importieren musste und erst dann ein positives Resultat erhielt. Danke an dieser Stelle für den Hinweis.

Hoffe, ich bringe irgendwann mal in Erfahrung, warum und wie die SK einfach deaktiviert werden können...

Viele Grüsse
Leo

Hoffe, ich bringe irgendwann mal in Erfahrung, warum und wie die SK einfach deaktiviert werden können...

NAV speichert in einer FBK-Sicherung keine Sekundärschlüssel-Werte (sondern nur die Schlüsseldefinitionen), um dadurch die Größe der FBK zu minimieren.

Wird nun die FBK zurückgelesen, so sind zwar alle Sekundärschlüssel in den Tabellen vorhanden, jedoch deaktiviert.
Aus diesem Grund muss NAV nach dem Import erstmal die Schlüssel aufbauen.
Bricht dieser Vorgang (aus welchem Grund auch immer) ab, so sind noch nicht alle Sekundärschlüssel erzeugt.

Guten Tag und Danke @ Timo Lässer für die Ausführungen.

Konnte inzwischen auch in Erfahrung bringen, dass versucht wurde, in die fehlerhafte Datenbank (DB, von welcher das .fbk erstellt wurde und in der neuen Datenbank keine SK aufbaute), ein .fbk einer früheren DB - mitsamt Objekten, gemeinsamen Daten etc. - einzulesen. (Begründung: "Fehlende Bewegungsdaten beim Testen. Daher wurde versucht, Cronus als zusätzlichen Mandanten einzurichten.")

Somit ist mir auch verständlich, warum dann im Object Designer die modifizierten Objekte im 1000000er-Bereich doppelt vorhanden sind und beim Einlesen des .fbk Probleme entstehen können.

Beste Grüsse
Leo