[Gelöst] Fehler bei Rücksicherung mit SQL Server

Folgende Situation :
2 Datenbanken, Datenbank A mit Add-on X, Datenbank B mit Add-on Y. Ein Mandant aus DB A soll nach DB B (bislang 3 Mandanten) eingelesen werden, dort also der 4. Mandant werden. „Kleine“ Besonderheit : In DB B sind 84 Tabellen mandantenübergreifend geschaltet.

Die Felder aus Add-on X in A sind alle geleert, da sonst die Rücksicherung sofort abbricht. Aus den Tabellen in DB A, die mandantenübergreifend in DB B sind, wurden alle Datensätze gelöscht.

Gesichert wird dann aus A in eine .fbk ohne mandantenübergreifende Daten und Applikationsobjekte.
Bei Verwendung der nativen Datenbank läßt sich dann die vorbereitete .fbk aus A in B einlesen. Beim Rücksichern in eine SQL-Datenbank (mit Client 4.0 SP 2) erscheint aber nach der Designaufbereitung und Schlüsselaufbau aller normalen Tabellen die Meldung:

DasiFehler.jpg

leider ohne Anzeige der fraglichen Tabelle.

Weiss jemand, wieso die native DB die Datensicherung einliest, die SQL-DB aber nicht bzw. wie man die dazu überreden kann? Eine native Zwischen-DB ohne User und Rollen hat leider auch nichts gebracht.

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

Hallo Kai,

ich konnte das Problem auch mit NAV 5.00 SP1 nachstellen. In meiner Db B habe ich einige Artikeltabellen global geschaltet. Nach einigen Tests in beide Richtungen konnte ich das Backup mit einem Trick zurückspielen:

• Native NAV 5.00 SP1 Addon Db dupliziert als DB_A.fdb und DB_B.fdb
• Sicherung DB_B.fdb als DB_B.fbk
• Anlegen einer neuen SQL Db (DB_B)
• Rücksicherung DB_B.fbk in SQL DB_B (komplett)
• Löschung aller Tabellendaten und Tabellenobjekte für mandantenübergreifende Daten in nativer DB_A.fdb
• Sicherung DB_A.fdb als DB_A.fbk (nur Daten des Mandanten, keine übergreifenden Daten oder Applikationsobjekte)
• Rücksicherung DB_A.fbk in SQL DB_B

Wichtig dabei: Vor dem Backup der DB A neben den Datensätzen auch die Tabellenobjekte löschen. Sprich Objectdesigner, mandantenübergreifende Tabellen filtern und F4!

Da ich zunächst etwas durcheinander gekommen war, hab ich alles ein zweites Mal durchgeführt: Ebenfalls erfolgreich.

---

Schönen Dank für die Unterstützung !

Ich hatte am Freitag noch ein bißchen getestet. Bei nativer DB klappt das ohne Löschen der Tabellen auch erst ab Version 5, bis 4 SP3 bricht der genauso ab.
Aber Dank deiner Hilfe kann ich mir jetzt den Versuch eines technischen Upgrades für die SQL-DB sparen.
Ich mach dann morgen eine Kopie und lösche aus der die mandantenübergreifenden Tabellen. Leider kann man diese ja nicht zuverlässig filtern (hatten wir hier ja schon mal als Thema), ich versuche es erst mal mit denen, die unter Datenbankinformationen angezeigt werden, und wenn das auch noch nicht reicht, dann alle.

Es funktioniert leider unter 4 SP2 auch mit Löschung aller mandantenübergreifenden Tabellen nicht mit dem SQL-Server. Ich habe die so vorbereitete .fbk noch mal testweise in eine native 4 SP3 eingelesen, dort geht die anstandslos rein. Ich werde wohl doch das ganze nun über Dataports einlesen müssen und die BLOB Felder über die Zwischenablage.

Hmm, und ein technisches Upgrade kommt nicht in Frage?

Hmm, und ein technisches Upgrade kommt nicht in Frage?

Vorher probiere ich noch ein gleichzeitige Rücksicherung aller 4 Mandanten aus der nativen Zwischen-DB in eine leere SQL-DB. Wenn das auch nicht funktioniert, wird wohl das Upgrade unvermeidlich sein.

Nachdem die zusammengeführte DB nun schon einige Wochen im Echtbetrieb reibungslos arbeitet, darf man das Problem wohl als gelöst betrachten.
So hat es dann geklappt:

• Aufbau einer nativen Zwischen-DB, groß genug für alle 4 Mandanten
• Import aller Objekte aus DB_B in die Zwischen-DB
• Alle mandantenübergreifenden Tabellen in DB_B wurden in DB_A gelöscht.
• Aus Datenbank A wurde der eine Mandant als fbk gesichert, ohne mandantenübergreifende Daten
• Aus Datenbank B wurden alle Mandanten als fbk gesichert, mit mandantenübergreifenden Daten
• Die erste (kleine) Sicherung wurde in die Zwischen-DB eingelesen
• Über einen Report wurden dann über die Tabelle Key alle non-clustered Sekundärschlüssel deaktiviert, um den Aufbau der zweiten (großen) Sicherung zu beschleunigen. Das funktioniert über einen Report nur, wenn auch ein Mandant vorhanden ist.
• Aus der Zwischen-DB eine gemeinsame fbk-Sicherung aller 4 Mandanten erstellt
• Aufbau einer neuen SQL-DB, einlesen des Objektstandes aus DB_B (alle Keys aktiviert)
• Einlesen der gemeinsamen fbk-Sicherung aller 4 Mandanten in die SQL-DB.

Dabei musste eine Add-On Tabelle kurzfristig umbenannt werden, weil dieser Name auch in dem anderen Add-On vorhanden war. Diese kann man natürlich ggf. auch gleich löschen, aber falls die Daten noch konvertiert werden müssen (das war hier der Fall, wegen vorhandenen Belegtexten), werden diese noch benötigt.