DbImport hängt sich auf

[blondervolker]

Hallo,
versuche aus meiner Access DB nach Absolut DB, vier Felder mit ca. 17000 Datensätzen zu importieren.(Erstversuch)
Aber bei ca.1400 Datensätzen hängt sich die Exe auf,(keine Rückmeldung).:oops:

Delphi-Quellcode:

procedure TForm1.Button2Click(Sender: TObject);
begin
//Übernahme Import Accdb Anfang
  ADOTable1.First;
  while not ADOTable1.Eof do begin
   AbsTable1.Edit;
    AbsTable1.Insert;
     AbsTable1.FieldByName('Preis').AsString := ADOTable1.FieldByName('Preis').AsString;
      AbsTable1.FieldByName('DEU').AsString :=  ADOTable1.FieldByName('DEU').AsString;
       AbsTable1.FieldByName('ENG').AsString :=  ADOTable1.FieldByName('ENG').AsString;
        AbsTable1.FieldByName('ITA').AsString :=  ADOTable1.FieldByName('ITA').AsString;
          ADOTable1.Next;
            AbsTable1.Post;
//Übernahme Import in Absolute DB Ende
end;
end;

[mkinzler]

Was jetzt, Bearbeiten oder Einfügen?

Delphi-Quellcode:

   AbsTable1.Edit;
    AbsTable1.Insert;

[Perlsau]

Wie MKinzler schon aufgezeigt hat: Ein Insert direkt nach einem Edit macht keinen Sinn. Du versetzt den aktuellen Datensatz in den Edit-Modus, ohne ihn via Post oder Cancel wieder daraus zu befreien. Es könnte daher sein, daß das anschließende Insert dazu führt, daß irgend ein Stack überläuft, nämlich der, der sich die Edit-Befehle merkt. Unübersichtlich ist auch die Reihenfolge von ADOTable1.Next und AbsTable1.Post gewählt: Besser wäre es hier, das Next ganz am Schluß des Schleifenrumpfes aufzurufen.

Und schließlich: Die Formatierung macht auch keinen Sinn. Besser wäre hier, die Zuweisungen im Verhältnis zu Edit und Post einzurücken:

Delphi-Quellcode:

procedure TForm1.Button2Click(Sender: TObject); // Übernahme Import Accdb Anfang
begin
  ADOTable1.First;

  while not ADOTable1.Eof do
  begin
    AbsTable1.Insert;
      AbsTable1.FieldByName('Preis').AsString := ADOTable1.FieldByName('Preis').AsString;
      AbsTable1.FieldByName('DEU').AsString :=  ADOTable1.FieldByName('DEU').AsString;
      AbsTable1.FieldByName('ENG').AsString :=  ADOTable1.FieldByName('ENG').AsString;
      AbsTable1.FieldByName('ITA').AsString :=  ADOTable1.FieldByName('ITA').AsString;
    AbsTable1.Post;

    ADOTable1.Next;
  end;
end;

So siehst du auch gleich, wenn ein Edit und ein Insert derselben Tabelle aufeinander folgen.

Noch eine Frage: Wieso ist Preis ein String? Damit kann man doch gar nicht mehr rechnen ...:?:

[blondervolker]

Erstmal Danke für die Tipps.
Ich geb mir Mühe... auch mit dem einrücken...:oops:

[blondervolker]

Hab alles so gemacht,aber nach ca. 500 Datensätzen hängt sich die Exe auf.
Keine Rückmeldung.:oops:Irgendetwas mach ich bestimmt verkehrt.:oops:

[Union]

Hast Du das vielleicht in einer Transaktion gestartet? Wie sieht die Hauptspeicherauslastung aus? Und was heißt konkret "hängt sich auf"?

[Medium]

Ich vermute einfach mal, dass die Operation zu lange dauert, und Windows das Programm als tot ansieht, weil es keine Messages mehr abarbeitet. Ein gelegentliches "Application.ProcessMessages;" in der Schleife könnte schon helfen.
Das Programm läuft allerdings, auch wenn Windows meckert, weiter. Du müsstest einfach nur lange genug warten.

[jaenicke]

Zitat:

Zitat von blondervolker (Beitrag 1224562)

Hab alles so gemacht,aber nach ca. 500 Datensätzen hängt sich die Exe auf.

Auch beim Debuggen? Und wenn ja in welcher Zeile?

[blondervolker]

Hab das "Miniprojekt" mit drangehangen.Aber nur mit ca.1000 Datensätzen.
Die Exen habe ich gelöscht.(16 MB)
Wenn ich auf Import drücke und die Form verschiebe,spinnt die Exe.
Das gleich passiert,wenn ich den Projektordner nur verkleinere...:oops:

[Sir Rufo]

"hängt sich auf" oder "spinnt" sind eine super Fehlerbeschreibung und würde ich bei einem DAU auch durchgehen lassen - er weiß es einfach nicht besser.

Jemand der selber programmiert, sollte es besser wissen (beschreiben können).

Also (mitdenfingernindernasepuhlundherauszieh) wie ist die genaue Reaktion des Programms?
Was zeigt der Taskmanager zu der Anwendung an?
Hast du das Programm schon mal mit den 1000 Datensätzen laufen gelassen und so ca. 30 Minuten abgewartet?
Tauchen in der DB die Datensätze auf?
Arbeitest du mit Transaktionen?

Ach ja, bislang hast du dich erfolgreich vor jeglicher Beantwortung von Fragen gedrückt.
Wenn du das nicht möchtest, dann würde ich dir ein Häkelkreisforum empfehlen, aber erwarte hier keine Lösungen.

[blondervolker]

Nee,Nee... ich hab mich nicht gedrückt,sondern in der Zwischenzeit habe ich das Teil im meiner vorherigen Antwort mit drangehangen.
Ich habe das Programm laufen lassen und die importierten Datensätze werden auch korrekt angezeigt.Die Speicherauslatung zeigt beim Import keine erhöhten Werte an.
Sir Rufo, an einem Häkelkurs habe ich noch gar nicht gedacht?!:thumb:

[Sir Rufo]

Zitat:

Zitat von blondervolker (Beitrag 1224591)

Nee,Nee... ich hab mich nicht gedrückt,sondern in der Zwischenzeit habe ich das Teil im meiner vorherigen Antwort mit drangehangen.
Ich habe das Programm laufen lassen und die importierten Datensätze werden auch korrekt angezeigt.Die Speicherauslatung zeigt beim Import keine erhöhten Werte an.
Sir Rufo, an einem Häkelkurs habe ich noch gar nicht gedacht?!:thumb:

Und ein

Delphi-Quellcode:

Application.ProcessMessages

in der Schleife (wie schon zuvor genannt) hast du natürlich auch schon probiert.

Tja, da kann man dann wohl nichts machen :roll:

[blondervolker]

Ehrlich gesagt bin ich leider noch nicht mit allen "Wassern"gewaschen.
Darum wollte ich auch gerne wissen,was oder warum das Programm beim Import
bzw. beim bewegen der Form schlagartig einfriert.:oops:
Application.ProcessMessages?

[blondervolker]

Application.ProcessMessages;
Ja das war es.Danke Sir Rufo :thumb:
Ich lade dich ein zum Häkelkurs.:thumb:

[Sir Rufo]

Augen auf beim Eierkauf (mal in fett markiert - die rote Farbe spare ich mir mal)

Zitat:

Zitat von Medium (Beitrag 1224568)

Ich vermute einfach mal, dass die Operation zu lange dauert, und Windows das Programm als tot ansieht, weil es keine Messages mehr abarbeitet. Ein gelegentliches "Application.ProcessMessages;" in der Schleife könnte schon helfen.
Das Programm läuft allerdings, auch wenn Windows meckert, weiter. Du müsstest einfach nur lange genug warten.

Dann solltest du wissen, wer den berechtigten Hinweis gegeben hat

[blondervolker]

Oh,Oh...Also geht das DANKE an Medium.:thumb:

[Perlsau]

Zitat:

Zitat von blondervolker (Beitrag 1224597)

Application.ProcessMessages;
Ja das war es.Danke Sir Rufo :thumb:
Ich lade dich ein zum Häkelkurs.:thumb:

Bei Import-Geschichten gehe ich, nachdem ich in der Vergangenheit selber des Öfteren vor ähnlichen Situationen stand, immer folgendermaßen vor:

1. Ich sortiere die Quell-Tabelle erstmal nach PK (Primary Key), um einen guten Überblick bei eventuellen Suchaktionen zu gewährleisten.

2. Ich füge Ausgaben in den Importprozeß ein, entweder auf einer Statusbar oder in Labels. So sehe ich immer genau den Fortschritt der Importaktion:

Delphi-Quellcode:

     DatMod.Dset_Level.IndexFieldNames := 'IDX_LEVEL';
     DatMod.Dset_Level.Last;
     StatusBar.Panels[0].Text := IntToStr(DatMod.Dset_Level.RecordCount);
     DatMod.Dset_Level.First;

     WHILE NOT DatMod.Dset_Level.Eof DO
     BEGIN
        StatusBar.Panels[1].Text := IntToStr(DatMod.Dset_Level.RecNo);
        StatusBar.Panels[2].Text := DatMod.Dset_Level.FieldByName('IDX_LEVEL').AsString);
        Application.ProcessMessages;
        DatMod.NeuSet_Level.Append;
        DatMod.NeuSet_Level.FieldByName('USER_LEVEL').AsString := DatMod.Dset_Level.FieldByName('USER_LEVEL').AsString;
        DatMod.NeuSet_Level.Post;
        DatMod.Dset_Level.Next;
     END;

So sehe ich immer genau, wo der Einleseprozeß gerade steht. Kommt es zu irgendwelchen Fehlern, sehe ich das daran, daß sich die Zahlen in Panel 1 und 2 nicht mehr verändern. Ich notiere mir diese Zahlen und starte nun mit dem notierten Record die Methode noch einmal. Angenommen, ich notiere den Record 500:

Delphi-Quellcode:

//     DatMod.Dset_Level.First;
     DatMod.Dset_Level.RecNo := 500;
     WHILE NOT DatMod.Dset_Level.Eof DO
     ...

Da der Fehler bei Record# 500 auftrat, steppe ich diesen durch und bemerke dann meist sofort oder auch erst beim zweiten oder dritten Versuch, woran es hakt. Bei mir waren es verschiedene Ursachen, z.B. war ein Feld in der Zieldatenbank als Not Null definiert, in der Quelldatenbank war aber in Record 500 kein Eintrag, also Null. Da kommt normalerweise eine Fehlermeldung der Zieldatenbank. Auf jeden Fall kannst du so dem Fehler leicht auf die Schliche kommen.

[jaenicke]

Und um das ganze nicht zu sehr durch die Statusausgaben und ProcessMessages zu bremsen, sollte man diese nur alle z.B. 100 Datensätze machen.

[Perlsau]

Zitat:

Zitat von jaenicke (Beitrag 1224632)

Und um das ganze nicht zu sehr durch die Statusausgaben und ProcessMessages zu bremsen, sollte man diese nur alle z.B. 100 Datensätze machen.

Kommt drauf an: Bei unter 100.000 Datensätzen mit nicht allzu komplexer Tabellenstruktur spielt es nicht wirklich eine Rolle, wenn ich da mal ein paar Minuten warten muß. Bei Millionen von Datensätzen mit zudem noch komplexer Tabellenstruktur kann die von mir vorgestellte Methode dagegen Tage dauern. Hier bevorzuge ich dann meist den SQL-Dump, das geht auf jeden Fall unvergleichlich schneller.

[Medium]

Noch flotter geht meiner Erfahrung nach der Ex- und dann wieder Import über CSV. Die meisten DBMS dürften das von Hause aus können, so dass nichtmals ein Programm nötig wäre, nur die jeweilige SQL Shell. (Es hilft natürlich ungemein, wenn die Datei lokal auf dem Server ist.) Das geht natürlich nur so lange gut, wie man keine weitern Prüfungen machen, oder komplexere Abhängigkeiten erzeugen muss. (Im gewissen Rahmen dank SPs und Triggern auch möglich, klaro.)
Edit: Ich weiss nur nicht, wie sich das dann mit BLOBs verhält. Dürfte problematisch sein.

[jaenicke]

Zitat:

Zitat von Medium (Beitrag 1224635)

Noch flotter geht meiner Erfahrung nach der Ex- und dann wieder Import über CSV.

Das ist bei uns umgekehrt gewesen. Wir hatten das vorher so gemacht...
Eine Datenbank mit mehreren Millionen Einträgen dauerte so dann aber z.B. Stunden und auch kleinere dauerten relativ lange.

Dann habe ich das ganze auf FireDAC umgestellt und spreche die beiden Datenbanken nun direkt an. Der Import dauert nun statt Stunden mit riesigen temporären Dateien nur noch ca. 20 Minuten. Und unsere kleinren DBs sind innerhalb von wenigen Sekunden durch statt in Minuten.

[Medium]

Wenn von SQL-Dump die Rede ist, verstehe ich das Auswerfen einer SQL-Script Datei mitsamt Tabellendefinitionen und etlichen INSERT-Statements. Mit diesen läuft es bei mir um Größenordungen langsamer als über ein CSV, und das CSV sollte wie gesagt auf dem Server lokal auf der Platte liegen. Damit war ich bisher eigentlich immer schneller als mit fein säuberlich alles einzeln mit einem INSERT einzuträufeln, auch wenn ich mir mit UniDAC fix ein Migrationstöölchen selbst zusammengestrickt habe und direkt von einer DB in die andere geschaufelt. :gruebel:

[jaenicke]

Zitat:

Zitat von Medium (Beitrag 1224646)

Damit war ich bisher eigentlich immer schneller als mit fein säuberlich alles einzeln mit einem INSERT einzuträufeln, auch wenn ich mir mit UniDAC fix ein Migrationstöölchen selbst zusammengestrickt habe und direkt von einer DB in die andere geschaufelt. :gruebel:

Ich mache das nicht einzeln, ich bereite immer Häppchen vor und schiebe die dann auf einmal in die DB. FireDAC hat einen entsprechenden Modus, bei dem die Inserts erst gesammelt und dann gesammelt abgeschickt werden.

[Medium]

Klar, das mache ich auch - von Hand - so dass sich nachher etwas ergibt wie

SQL-Code:

INSERT INTO foo (field1, field2, field3) VALUES (0, 1, 2), (3, 4, 5), (6, 7, 8), ...

, und das ca. so lang, wie die max-Länge es zuließ. Aber dennoch flitzt mir der CSV-Import davon. Kann ich mangels geeigneter DB bzw. Daten gerade nicht schnell mit Messungen belegen, und auf nicht schnell hab ich grad keine Lust :). Fakt ist, dass ich nach Unzufriedenheit mit o.g. Methode nach Alternativen im Netz suchte, und bin dabei eben erst auf CSV gestoßen und fühlte mich glücklicher. Wenn mal Luft ist ne Test-App bauen.
(Bei mir war es übrigens meist MySQL, und ich meine auch mal ein MSSQL so sehr flott gefüttert zu haben.)

[Union]

Wie stellst Du dann binäre Blobdaten im CSV dar? Hexcodiert?

[Medium]

Schon beantwortet ;)

Zitat:

Zitat von Medium (Beitrag 1224635)

Ich weiss nur nicht, wie sich das dann mit BLOBs verhält. Dürfte problematisch sein.

Ich tendiere ohnehin eher dazu, Dateien im Filesystem zu erstellen und diese dann nur per Pfad zu referenzieren. Die Nachteile davon sind mir bewusst, bisher brauchte ich dass auch nur in zwei sehr kleinen Fällen, wo z.B. konkurrierende Zugriffe defacto kein Thema waren, und die nur bei uns intern eingesetzt werden.
Bei BLOBs dürfte das daher eher keine Option sein. Denkbar wäre noch - das müssten aber beide beteiligten DBMS unterstützen - der Weg über Base64*. Weiss ich aber nicht, nie gemacht, keine Ahnung wie das die Performance beeinträchtigen würde im Vergleich zu Stream-to-Stream mit INSERTs.

Edit *) Müsste doch aber eigentlich gehen, oder wie machen die DBMS das mit BLOBS bei einem SQL-Dump? Das sind ja auch nur Textfiles. Wie dem auch sei: Ich bin BLOBs bisher wenn möglich ausgewichen, und kann daher dazu keine wirklich qualifizierte Aussage machen. War in dem Fall hier imho aber auch nicht nötig für den TE.

[Union]

Bei MySQL sieht dann ein Insert so aus:

Code:

'0x...'

[Furtbichler]

Die meisten RDBMS unterstützen 'Bulk Inserts'. In die Richtung würde ich tendieren, wenn es mehr als 1000 Datensätze sind.

Bei MSSQL genügt der 'BULK INSERT' Befehl, aber dann ohne Progressbar. Über die API könnte das SqlBulkCopy-Objekt verfügbar sein, das Callbacks unterstützt.

Firebird unterstützt externe Tabellen. Ob das das Schnellste ist, weiß ich nicht, aber das Feature ist nett.

MySQL kennt 'LOAD DATA', Oracle 'BULK COLLECT'.

Wenn es nicht gerade ein Hinterhof-RDBMS ist, sollte das passende zu finden sein.

Ein BULK INSERT in MSSQL geht sehr schnell: 100.000 Datensätze in 1-2 Sekunden.

[Perlsau]

Zitat:

Zitat von Medium (Beitrag 1224646)

Wenn von SQL-Dump die Rede ist, verstehe ich das Auswerfen einer SQL-Script Datei mitsamt Tabellendefinitionen und etlichen INSERT-Statements. Mit diesen läuft es bei mir um Größenordungen langsamer als über ein CSV, und das CSV sollte wie gesagt auf dem Server lokal auf der Platte liegen. Damit war ich bisher eigentlich immer schneller als mit fein säuberlich alles einzeln mit einem INSERT einzuträufeln, auch wenn ich mir mit UniDAC fix ein Migrationstöölchen selbst zusammengestrickt habe und direkt von einer DB in die andere geschaufelt. :gruebel:

Ich hatte das mal mit OpenStreetMap-Daten getestet, die ja bekanntlich riesig sind: Das Einlesen via Delphi-Code dauerte Tage, via SQL-Dump dagegen nur Stunden.