Datenimport

[Martinha]

Hi,

aus mir völlig unerklärlichen Gründen startet des Datenimport nicht.
Ich habe jetzt scho 2 Stunden lange gelesen...habe aber keine Lösung gefunden.

Bis jetzt hatte ich den Import problemlos im SSMS, aber er tut es nicht mehr. Auch nicht als standalone Anwendung.

Irgendetwas scheint mit der Datei dtswizard.exe nicht zu stimen...
Umfeld vermutlich 32-64 Bit Umfeld.

Ich habe Visual Studio installiert und auch SSIS...

Danke für Hilfe.

Martin

 

[dabadepdu]

Irgendetwas scheint mit der Datei dtswizard.exe nicht zu stimen...

Gibt es Gründe für diese Vermutung?

Hilfreich sind immer Fehlermeldungen.

Ist dein "Datenimport" ein eigenes Script? Oder nur der Wizard selbst?

Wurden Updates eingespielt? (automatisch?)

32 - 64 bit

Wenn Du da etwas vermutest, was hat sich an diesem Umfeld geändert?
Und wenn es Dir unbekannt ist, eine Benennung von Version, Bitness der von Dir verwendeten Komponenten ist hilfreich.

 

[Martinha]

Wenn ich den Import aus SSMS aufrufe, passiert gar nix, eine Fehlermeldung erschein nicht.

Wenn ich ihn aus dem Explorer aufrufe, erscheint diese Meldung.

Es ist ein Fehler aufgetreten, der vom SQL Server Integration Services-Assistenten nicht behandelt werden konnte. (SQL Server-Import/Export-Assistent)

===================================

Die Datei oder Assembly "Microsoft.DataTransformationServices.ScaleHelper, Version=16.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden. (DTSWizard)

------------------------------
Speicherort des Programms:

bei Microsoft.SqlServer.Dts.DtsWizard.DTSWizardForm.GetPageSize()
bei Microsoft.SqlServer.Management.UI.WizardForm.OnLoad(EventArgs args)
bei System.Windows.Forms.Form.OnCreateControl()
bei System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
bei System.Windows.Forms.Control.CreateControl()
bei System.Windows.Forms.Control.WmShowWindow(Message& m)
bei System.Windows.Forms.Control.WndProc(Message& m)
bei System.Windows.Forms.Form.WmShowWindow(Message& m)
bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Auf zwei anderen Rechnern startet der Import problemlos.
Es gibt auch ein Windows bzw. DB SQL Fix, was ich auch installiert habe...ohne Erfolg.

Gibt man die Fehlermelduing ein, kommen alle möglichen Seiten, wo man aufgefordert wird, Tools zu installieren, wo das fehlener DTswizard.exe insalliert werden soll. Habe ich alles gemacht, aber wahrscheionlich falsch...
Also zurück auf Los, ich denke, ich werde die ganz DB Sql Installation neu aufsetzen.
Da es sich um die Entwicklungsumgebung handelt ist das kein Problem.
In der Produktion läuft es ohne Probleme.
Die Daten kann ich einem Backup aus der Produktion wieder herstellen.

Es soll morgen regnen...

Martin

 

[dabadepdu]

Es soll morgen regnen...

Es ist trocken

Ich habe dazu ein paar Seiten angeschaut und es so verstanden, dass das Problem ein Konflikt zwischen dem installierten Office und DBWizard ist.
DBWizard ist (immer?) 32 bit, Office kann beides sein, 32 oder 64. Das ganze scheint durch ein Update von irgendwas verursacht zu sein (allerdings schon vor 2 Jahren). Systemupdate könnte also helfen. Einspielen diverser Serverkomponenten (die m.E. nicht auf ein Clientsystem gehören) war auch ein Tipp.
Am Ende tuts vielleicht auch einfach ein 32 bit Office.
Ich kann es hier nicht weiter nachvollziehen, ich benutzte das nicht.

 

[t-sql]

Ist ziemlich wenig Information. Was soll wie importiert werden?? Wozu brauchst Du den SSIS?

 

[Martinha]

Hi,

also ich habe mir da etwas gebastelt, was sehr gut funktioniert:

Ziel ist; eine andere Datenbank (Sandbox) mit Daten aus der produktiven DB (Produktion) zu füllen.
In Sandbox kann man dann Dinge testen, ohne die Produktion zu gefährden. Das sollte möglichst mit einem Klick in dem Access-FE passieren, ohne ins SSMS wechseln zu müssen.

Ich habe es versucht, mit Backup aus Produktion und dann Restore in Sandbox, bekam aber immer alle möglichen Fehlermeldungen, so das ich nach anderen Lösungen suchte. Das Probleme dabei war oft, das die Ziel-Datenbank als single-user sein musste und, wenn da was hing , der Zustand irgendwie stubbelig war.

Zunächst lösche ich alle Daten in Sandbox, indem ich die Personen lösche, durch RI-Beziehungen werden alle andere beteiligten Tabellen gelöscht.
Dazu rufe ich eine Stored Procedure in Sandbox auf.
Die Datenbank ist dann quasi leer, bis auf einige Schlüsseltabellen, die sich eigentlich nicht ändern.

Dann habe den Datenimport im SSMS über "tasks" benutzt und importiere Tabelleninhalte aus der Produktion und speicherte diesen Vorgang in einer .dtsx Datei (dazu das SSIS).
Das mache ich von "unten nach oben" gemäß den RI-Regeln.
Diese Importe speichere ich, um sie wieder verwenden zu können.

Als ich alle Datenimporte hatte, erstellte ich in Access eine bat-Datei mit den .dtsx-Aufrufen in der richtigen Reihenfolge, die per dtexec nacheinander ausgeführt werden.

Z.B.

dtexec /f "C:\DbAdcDevelopment\sqls\FillSandboxfromProduktion\Person_from_prod.dtsx"

Diese .bat Datei mit den dtexec Befehlen führe ich mit einem shell Befehl aus und sie rennt los.
Meine DB ist ziemlich klein und das Ganze ist in weniger als 1 Minute erledigt.
Als Ergebnis ist in Sandbox der aktuelle Datenbestand aus der Produktion...works as designed.
Schön wäre es, wenn es den "Copy Database" Befehl auch in SQLEXPRESS geben würde, gibt es aber nicht.

Der große Vorteil ist, ich muss das Access-FE nicht verlassen, der neue Datebestand ist sofort da, per Klick.

Ich hoffe, ich konnte mich erklären...wenn noch Fragen sind...gerne.

Gruß

Martin

 

[dabadepdu]

dtexec /f "C:\DbAdcDevelopment\sqls\FillSandboxfromProduktion\Person_from_prod.dtsx"

Ok, jetzt kennen wir den Befehl (allerdings nicht den Inhalt von dtsx, dürfte aber wahrscheinlich egal sein für das Problem)

Dein "Softwarestack" scheint durch ein (bereits älteres) Update von MS Komponenten in sich nicht (mehr) kompatibel zu sein.
Eine mögliche Lösung ist wie bereits geschrieben, die Bitness der Officekomponenten an die Bitness von DB Wizard anzupassen (also alles 32 bit). (Und das hat nichts mit der Bitness des Servers zu tun).

Da ich das nur aus ein paar Foreneinträgen gelesen habe, solltest Du vor weiteren Installationsexperimenten versuchen, die mögliche Lösung bzw. das Problem anhand der Hinweise einzugrenzen. Ich kann es nicht nachvollziehen bzw. vertiefen, da ich keine solchen MS Programme nutze.

Ein guter Ansatz, sowas einzugrenzen, ist ein Test innerhalb einer neuen, nackten VM. MS Virtualisierung gibt es jenachdem (Betriebssystemedition) sowieso geschenkt, wenn ich mich richtig erinnere.