DbImport hängt sich auf

[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.