[gelöst] Import "riesiger" Datenmengen

[spf]

Hallo Community,

folgendes Problem:
Ich habe den Auftrag Daten aus einer *.txt Datei nach NAV zu importieren was im Grunde kein Problem darstellen sollte, nun bin ich allerdings (glaube ich) an die grenzen gestossen.
Die Datei beinhaltet ca. 2mio Zeilen (fast 6GB gross), auf 84 Spalten. Diese sind so lang, das sogar die maximale länge eines Datensatztes (4000kb) überschritten wird. Also muss das ganze in 2 Tabellen.

Ein Dataport braucht, wenn ich die datei in einem einlese ~10 sekunden für einen datensatz, was inakzeptabel ist.
Wenn ich über Excel gehe und dann das RIM-Toolkit benutze bricht der Import nach ~12000 Zeilen ab, wovon ca. 30% als Fehlerhaft angezeigt werden. Die restlichen Zeilen bleiben "übrig".

Die Forensuche hat leider kein Befriedigendes ergebnis geliefert, ebensowenig wie Google. Gibt es einen "Trick" den man bei solchen Datenmengen anwenden kann bzw. eine Methode das ganze zu verkürzen oder bleibt mir nichts anderes übrig als die datei so klein zu machen wie es geht und dann alle teile nacheinander zu importieren.

Ich hoffe man kann mir noch helfen,

spf

Zuletzt geändert von spf am 2. Dezember 2009 16:11, insgesamt 1-mal geändert.

schaum mal bei dotnetpro.de. Da gabe es mal einen Wettbewerb Dateien mit mehr als 500.000 Zeilen schnellsten in eine DB zu bringen. Vielleicht ist da was dabei, das Du in leicht geänderter Form nutzen kannst z. b. indem Du 2 xml-Dateien erstellst).

Volker

Müssen die Datensätze wirklich nach Navision?

mitunter ist es ausreichend diese Daten mit SQL Bordmitteln in SQL Tabellen zu schreiben und diese NUR nach Navision "ranzulinken".

Danke erstmal für die Hinweise, ich schaue mich grad auf dotnetpro.de um.

Müssen die Datensätze wirklich nach Navision?

mitunter ist es ausreichend diese Daten mit SQL Bordmitteln in SQL Tabellen zu schreiben und diese NUR nach Navision "ranzulinken".

Die Daten sollen später in die Kontakttabelle Integriert werden (nicht alle natürlich, aber die meisten), darum denke ich das es sinnvoll wäredie Daten direkt in NAV zu haben, sofern nicht die möglichkeit besteht diese aus den SQL tabellen in die Kontakttabelle zu transportieren
(Kleine anmerkung hier: Ich habe kaum/nur sehr geringe SQL-Kentnisse)

~spf

mit "wirklich" nach Navision meinte ich "richtige" Navision Tabellen. Die gelinkten Tabellen stellen sich genauso dar, nur dass sie woanders stehen. Sie sind aber in Navision sichtbar und weiterverarbeitbar.

Ah, okay.

Das sollte soweit in Ordnung sein, das anschließende einfügen in die Kontakt-Tabelle betrifft dann ja nicht alle Daten, das sollte von da an kein Problem mehr darstellen.
Wie lässt sich das ganze denn am einfachsten realisieren, sodass ich das ganze weiterverarbeiten kann.

~spf

Hallo spf,

das sollten eigentlich keine Daten sein, die einen schrecken müssten.

Zunächst mal ein paar Fragen für mich zur Klärung,

• Wie lang ist eine Zeile maximal?
• Wie lang ist ein Feld in der Zeile maximal?
• Hast du fixe oder variable Datensatzlänge?

Gruß, Fiddi

Hallo fiddi,

ich habe mich jetzt mal mit einem mitarbeiter zusammengesetzt der sich mit sql auskennt, meine "befürchtungen" sind also nun nichtmehr so gross.
Wir haben nun auch den lösungsansatz von tba beherzigt und probieren da ein wenig herum.

Zu deinen fragen:

> 6680 Zeichen sind in einer Zeile (in jeder; leerzeichentrennung der einzelnen Felder)
> 255 Zeichen sind das maximum eines Feldes
> Die Textlängen sind unterschiedlich; aber immer in fixen abständen (Erste "spalte" hat 100 Zeichen, die zweite 60 usw.)

Gruß

~spf

Hallo spf,

da du nur minimale SQL Kenntnisse hast kann es schwierig sein das umzusetzen. Für Massendaten empfiehlt sich, wie schon angesprochen, SSIS des SQL Servers. Kurz und knackig würde ich mir eine Dump Tabelle in Navision erstellen und anschließend im Business Intelligence Studio ein neues SSIS Projekt starten. Im Control Flow dann ein Data Flow Element eintragen (vgl. Bild 1/2) und eine Quelle (hier Flat File) auswählen. Anschließend Destination (im Muster super simpel dargestellt mit Option OLE DB und Flat File). Mal angenommen es gibt keine Transformierung, kann es klappen. Ich empfehle immer erstmal die Flat zu Flat Variante für try and error und ein wenig Lektüre (bspw. Business Intelligence und Reporting mit Microsoft SQL Server 2xxx).

Ich hoffe das war etwas verständlich.

Gruß
defiant701

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

Hallo defiant701,

danke für deine Antwort, das ganze hilft mir auf jeden fall weiter; ich habe mich (wie oben beschrieben) nun mit jemand zusammengesetzt der des SQL mächtig ist und mich da durchlotst.

~spf

Hallo spf,

so wie du das beschreibst, ist das kein Problem für einen Dataport.

Definiere für jedes Feld eine globale Variable z.B. Feld1, Feld2, Feld3,... (oder irgendwas sinnvolleres , es darf auch ein Array sein). Es sollte sich dabei um eine Textvariablen mit einer Länge von mindestens 260 Zeichen handeln. In dem Dataport definierst du eine Tabelle, die deine Daten hauptsächlich erhalten soll oder du nimmst die Tabelle Integer. Als Felder nimmst du nun deine vorher definierten Textvariablen, und keine Felder aus der führenden Tabelle. Im OnAfterImport- Trigger kannst du nun diese Textvariablen auswerten und auf die korrekten Tabellen verteilen, unter der Berücksichtigung der Bussines-Logik von NAV (zumindest wenn du mit Validate und INSERT(true)/MODIFY(true) arbeitest.

HINWEIS: Vermeide es direkt in NAV-Tabellen mit SQL zu schreiben. Es wird dann keine Programm- Logik aus NAV ausgeführt, und z.B. von den geänderten Tabellen abhängige Tabellen nicht aktualisiert.

Gruß, Fiddi

Mit einem Dataport hatte ich das ganze auch schon Probiert, dort trat dann nach einer bestimmten Zeit das Problem auf, das der Zielpuffer voll war und der Import abbrach.
Zumal ist 1 Datensatz alle ~10 sekunden nicht so ganz das Optimum bei so einer Masse an Daten, das es dann einige Jahre importzeit benötigen würde; Diese Zeit habe ich nun leider nicht ;)

Die SQL variante bietet sich an, da ich die Daten vorerst einfach nur Abbilden muss. Wenn ich danach aus NAV mit den daten weiterarbeiten kann (sprich: notwendiges in die jeweiligen tabellen transportieren) ist soweit alles in ordnung.

~spf

Hallo,

arbeitest du mit einer lokalen Datenbank? Wenn ja, prüfe bitte den DBMS-Cache des Clients, er darf bis zu 1GB sein, und das sollte man so nutzen, das der PC danach noch midestens 100 MB freien Arbeitsspicher hat.
Bei einem SQL-Server lege bitte die Datenbank und das LOG von der Größe her so an, das von vorn herein genügend Platz in den DB-Dateien ist und lass den SQL-Server die DB nicht immer nur um ein paar MB größer werden, dann ist er nur noch mit DB- Vergrößern beschäftigt.

Wieviel Platz ist noch in einer native -DB, es sollte dort mindesten 70% freier DB-Platz sein, (auch nach dem Import). Bitte DB vergrößern.

Wie oft machst du ein COMMIT, alle 100 Datensätze darf das schon sein.

Gruß, Fiddi

So, hier mal ein kleines Update:

Ich habe das ganze jetzt via SQL gelöst, es hat alles prima geklappt und war wesentlich schneller als ein Dataport, den ich nochmals angepasst hatte nach fiddis post oben.

Danke nochmal für eure super Hilfe!

~spf