Alternative zu While

[value is NULL]

Hey Leute

Hab irgendwie ein kleines denkproblem ...
Habe ein GUI gemacht, welches die daten von einer Datenbank in eine andere übernimmt.
Dazu lese ich mir aus wieviel records table X hat und gehe dann in enie While schleife rein:

Delphi-Quellcode:

while f < calltaglist.Count do begin
  ... inserts ...
  f := f + 1;
end;

Jetzt habe ich das Problem, das ich dort knapp 600.000 Einträge habe und es natürlich ein bisschen dauert, bis alles übernommen ist.
Während des Imports ist mein Programm quasi "eingefrohren".-

Gibt es eine Möglichkeit meine While zu ersetzen, so dass man das GUI zumindest verschieben kann oder einen Button wie zB abbrechen betätigen kann?

Vielen Dank schon mal

LG

[sirius]

Alternative: Threads

[value is NULL]

ich gebe zu, ich habe bis dato keine Threads benötigt...

Dh. das wäre dann in etwas so vorstellbar?

Delphi-Quellcode:

function inserts(): LongInt; stdcall;
begin
 //Do the inserts ...
end;

var
 ThreadID: DWORD;       //Thread-ID
 ThreadHandle: THandle; //Rückgabewert von CreateThread

begin
 ThreadHandle:=CreateThread(nil, 0, TFNThreadStartRoutine(@inserts),
 nil, 0, ThreadID);

 if ThreadHandle<>0 then CloseHandle(ThreadHandle);
end.

Kann sein das ich mich jetzt blamiere ;) aber ich hatte davor wirklich noch nichts damit zu tun.

danke trotzdem schon mal

LG

[himitsu]

TThread?

Aber es gibt ja genügend Tutorials für VCL- (TThread) und NonVCL-Threads (CreateThread).
Du darfst nur nicht vergessen, daß du nicht einfach so das DataSet aus der VCL, welches z.B. vielleicht auch noch "aktiv" an irgendeinem Grid hängt, im Thread zu verwenden, da Datasets nicht grade threadsave (gleichzeitige Zugriffe aus unterschiedlichen Threads) sind.


Als Billig-Lösung kann man auch ein paar Application.ProcessMessages in die Schleife einstreuen (nur nicht zu häufig), um der GUI die Möglichkeit zu geben "Messages" zu verarbeiten, über welche z.B. das Verschieben abgehandelt wird. :angle2:

[Jumpy]

600 Tsd. Datensätze ist ja schon was. Vllt. gibt es da generell eine bessere Lösung um die auf einmal aus der einen DB zu holen und in die andere zu "blasen". Kommt natürlich auf die DBs an und was die vllt. für Tools dazu anbieten.

Ansonsten zu Threads:
http://www.delphi-treff.de/tutorials...ds/einleitung/

[value is NULL]

also danke schon mal für die vielen Antworten ...

Habe jetzt viel gelesen aber bin noch nicht wirklich schlauer. Habe mir ein kleines Testprogramm gemacht:

Delphi-Quellcode:

unit testcode;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type
  TForm1 = class(TForm)
    start: TButton;
    Memo1: TMemo;
    abbrechen: TButton;
    procedure startClick(Sender: TObject);
    procedure abbrechenClick(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

  function inserts() : string;

var
  Form1: TForm1;
  ThreadID: DWORD;
  ThreadHandle: THandle;

implementation

{$R *.dfm}

function inserts() : string;
var
  i : integer;
begin
  i := 0;
  while i < 10000 do begin
    Form1.Memo1.Lines.Add('Number '+inttostr(i));
    sleep(1000);
    i := i + 1;
  end;
  EndThread(0);
end;

procedure TForm1.abbrechenClick(Sender: TObject);
begin
  // ?
end;

procedure TForm1.startClick(Sender: TObject);
begin
  ThreadHandle:=CreateThread(nil, 0, TFNThreadStartRoutine(@inserts), nil, 0, ThreadID);
end;

end.

was müsste ich tun, damit bei TForm1.abbrechenClick der Thread beendet wird bzw. wann weiß ich in startClick wann function inserts fertig ist?

Danke und LG

[Zacherl]

TThread ist hier wirklich viel einfacher. Da kannst du den Thread mit der Methode Terminate beenden. Innerhalb deiner eigentlichen Berechnung prüfst du dann einfach auf die Terminated Eigenschaft. Außerhalb des Threads solltest du dann aber nach der Terminierung noch mit WaitFor auf das Ende des Threads warten, bevor du ihn wieder freigibst.

[value is NULL]

geil flutscht! ;)

Habe folgende schnippsel im Netz gefunden:

Start Thread

Delphi-Quellcode:

Function StartThread(pFunction : TFNThreadStartRoutine; iPriority : Integer = Thread_Priority_Normal; iStartFlag : Integer = 0) : THandle;
var
  ThreadID : DWORD;
begin
  Result := CreateThread(nil, 0, pFunction, nil, iStartFlag, ThreadID);
  if Result <> Null then
  SetThreadPriority(Result, iPriority);
end;

Close Thread

Delphi-Quellcode:

Function CloseThread( ThreadHandle : THandle) : Boolean;
begin
  Result := TerminateThread(ThreadHandle, 1);
  CloseHandle(ThreadHandle);
end;

[himitsu]

Zitat:

Delphi-Quellcode:

function inserts() : string;

Wieso so?

Schau mal wie TFNThreadStartRoutine deklariert ist und wenn da nichts steht, dann schau in der Deklaration der entsprechenden Funktion nach.
Bei dir ist gleich alles komplett falsch ... Parameter, Rückgabetyp und Aufrufkonvention.

Fast immer dann, wenn du solche brutalen Casts machen mußt, welche auch noch Delphis eingebaute Prüfung auf Typsicherheit umgehen, solltest du dir dringend überlegen was du da überhaupt machst und ob du da nicht irgendwelchen Mist baust.

Zitat:

Delphi-Quellcode:

Form1.Memo1.Lines.Add

Und dann greifst du innerhalb deines Threads direkt auf die VCL zu.
Das macht man nicht.
Sowas hat man gefälligst zu synchronisieren! :warn:

[Bbommel]

Ich möchte mal fies in die ganze TThread-Lösung hier reingrätschen. :) Die ist natürlich von der Idee her ein völlig richtiger Ansatz und wenn man sich eh mal mit Threads beschäftigen will, wäre das hier auch ein schönes Ding zum Üben, aber: wenn es nur eine GUI ist, die eh nichts anderes kann, als diese Daten-Migration, und man etwas basteln will, damit die GUI für den Benutzer nicht eingefroren erscheint, dann könnte das gute alte Application.ProcessMessages die einfachere und schnellere Möglichkeit sein, zum Ziel zu kommen.

Man kann alle paar hundert oder auch tausend Durchläufe mal Application.ProcessMessages aufrufen, sodass dann alles, was der Benutzer zwischenzeitlich geklickt und verschoben hat, verarbeitet wird. Auch ein Abbrechen-Button, wenn man dabei eine passende Abbruch-Bedingung für die while-Schleife setzt. Vielleicht hilft das ja weiter, an der richtigen Stelle zu suchen.

Wie gesagt, nichts gegen Threads, fände ich aber hier die einfachere und pragmatischere Lösung.

Bis denn
Bommel

[p80286]

Zitat:

Zitat von Bbommel (Beitrag 1185422)

sodass dann alles, was der Benutzer zwischenzeitlich geklickt und verschoben hat, verarbeitet wird.

und in dem "alles" ist dann der Hund begraben. Da bekommst Du unter Umständen Multitasking durch die Hintertür.

Wenn Du mit mehreren Threads arbeitest, dann ist (sollte) Dir bewußt, daß du auf mehreren Hochzeiten tanzt. Ohne Threads arbeiten verleitet da zum schludern.

Gruß
K-H

[Bbommel]

Hm, sehe ich jetzt hier für das einfache Beispiel nicht so als Gefahr. Klar, man könnte etwas falsch machen, weil man irgendwo einen Nebeneffekt übersieht oder einen Button, der während der Laufzeit der while-Schleife dann etwas macht, was er zu der Zeit nicht machen sollte (ich denke mal, so etwas wirst du meinen?).

Aber Stolpersteine hat man bei Threads ja genauso, wie man ja direkt hier in dem Beispiel sehen konnte: mal direkt ohne ein Sync auf die VCL zugegriffen, ist sicherlich genauso ein Klassiker. :)

Wie gesagt, gilt natürlich alles nur für die einfache GUI, die "value is null" hier beschrieben hatte.

[himitsu]

PS: Siehe letzte Zeile in Beitrag #4 :angle:

Was man z.B. vergessen kann:
- Button disablen (der Prozess läßt sich mehrfach starten und der Zugriff "globalere" Variablen macht schnell mal Probleme)
- Wenn die Funktion auf die Form/GUI zugreift und man schließt die form, bevor die Prozedur fertig ist.
- ...

Nja, das Selbe trifft aber auch auf den Thread zu:
- den Thread kann man mehrmals starten
- der Zugriff auf globale Dinge muß abgesichert werden (vorallem der unsynchronisierte Zugriff auf die GUI)
- wenn etwas aus der form verwendet wird, dann darf diese auch vorher nicht freigegeben werden
- ...

[Bbommel]

Zitat:

Zitat von himitsu (Beitrag 1185438)

PS: Siehe letzte Zeile in Beitrag #4 :angle:

Ups, hatte ich tatsächlich übersehen, 'tschuldige. :)

Ansonsten sehe ich es genauso: man muss einfach in beiden Fällen darauf achten, dass in der GUI alles sauber abgefangen wird.

[Captnemo]

Wenn's mal schnell gehen soll, dann mache ich das so:

Also wenn ich so eine Schleife, die so viele Datensätze verarbeiten soll, dann sollte man ggf. mit einer Progressbar dem Anwender zeigen, das die Verbeitung noch läuft, bzw. wielange sie noch läuft. Ich persönlich blende dafür immer einen eigenen Dialog ein, der mit einer Progressbar und einem Abbrechen-Button bestückt ist.
Innerhalb der Schleife, sorge ich mittel Application.Prozessmessages dafür, dass meine Progressbar aktualisiert wird. Dann nehme ich eine globale Bool-Variable, die mit dem Abbrechen-Button setze, und innerhalb der While-Schleife abfrage.

[Luckie]

Man sollte aber besser BeginThread nehmen, weil das die globale Variable IsMultiThreaded setzt und so den Heap threadsafe macht.

[QuickAndDirty]

Wenn du MSSQL benutzt wäre ein Bulk-INSERT das mittel der Wahl....
Das kürzte bei uns Operationen die nach über 2 Tagen noch nicht fertig waren massiv ab auf unter 20 Minuten.
Es ist dabei nur wichtig das der Pfad in dem die Bulkdatei gebaut wird auch für den SQLServer im zugriff sein muss. Also am besten auf dem selben PC.

Sowas ähnliches müsste eigentlich fast jede DB haben. In Firebird benutzt man z.B. für sowas "External Tables", in MYSQL den "LOAD DATA INFILE" Befehl usw...

[Medium]

Das war jetzt auch mein erster Gedanke. Die meisten DBMS bieten zumindest die Möglichkeit, Daten als CSV zu ex- und importieren, was i.A. ziemlich zügig geht. Wenn man also nur einmalig migrieren möchte, ließe sich das schnell und einfach in der SQL Konsole machen, und auch wenn es um regelmäßige Infusionen solcher Mengen geht wäre es gut denkbar diesen "Umweg" über ein CSV zu gehen, nur dann eben hübsch in ein Programm verpackt.

Noch ein Tipp: INSERTs sind relativ kostspielig, man kann aber mehrere Datensätze in ein INSERT packen: "INSERT INTO foo (feld1, feld2, feld3) VALUES (wert11, wert21, wert31), (wert12, wert22, wert32), ..."
Da beschränkt einen nur, wie viel Zeichen dein DBMS pro Statement verarbeitet, und ggf. begrenzung durch die Datenbankkomponente bzw. den Kommunikationsweg. Je nach Tabelle und DBMS kann es aber auch ab einer gewissen Anzahl Datensätze wieder langsamer werden. Ich hab für ein Tool mit MySQL zwischen 8 und 32 Sätze pro INSERT bisher die besten Zeiten gesehen, wobei es aber halt immer auch an den Tabellen selbst hängt (Feldanzahl, Art und Menge der Keys, Trigger...).