Ok also wie gesagt hab ich mich mal an den Thread gewagt und die Rückgabe in eine VirtualTable gelegt.

1. Problem, ich habe zur schnellen Überprüfung einfach ein DBGrid benutzt, manchmal jedoch nicht immer kommt es zu der Meldung: Canvas erlaubt kein zeichnen, gestoppt wird in VCL.Graphics Zeile 4197 Da weiss ich gerade auch nicht warum der Fehler auftritt.

2. Ein weiteres Problem zu dem es kommen kann und da wird es richtig wild, (Ich hab zum Test das Create, Start des Thread auf einen Button gelegt, wenn dieser aber zu schnell hintereinander geklickt wird haut es mir ziemlich viele Exceptions um die Ohren, angefangen von Blob Fehler bis hin zu (Gitternetz irgendwas, müsste ich noch mal genau nachsehen.)

Gut das kann ich schnell umgehen in dem ich einfach den Button so lange sperre wie der separate Thread läuft. In der späteren Hauptanwendung benutze ich ein PageControl, welches beim Seitenwechsel quasi den Thread starten soll um die GUI (Grid und weitere DBControls) mit den Werten zu füllen, da müsste ich mal sehen wie ich das unterbinde das die Seiten zu schnell gewechselt werden.

Dann schmeiss ich mal den Code hier rein und hoffe mir kann da jemand auf die Sprünge helfen bezüglich obiger Probleme (Ich geh einfach mal davon aus, mein Thread hat einen Designfehler oder die Hauptanwendung oder beides )

Die Anwendung:

zusammenfalten · markieren

Delphi-Quellcode:

unit fmView;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants,
  System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Data.DB, Vcl.StdCtrls, Vcl.ComCtrls,
  MemDS, VirtualTable, DBAccess, Uni, Vcl.Grids, Vcl.DBGrids,

  QueryThread;

type
  TView = class(TForm)
    DBGrid1: TDBGrid;
    UniDataSource1: TUniDataSource;
    VirtualTable1: TVirtualTable;
    StatusBar1: TStatusBar;
    MSGLog: TMemo;
    Label1: TLabel;
    btnStart: TButton;
    edtConStr: TEdit;
    edtSqlTxt: TEdit;
    QrPB: TProgressBar;
    procedure btnStartClick(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
  private
    { Private-Deklarationen }
    FSQLThrd: TSqlQueryThrd;
    procedure OnThreadStatusMsg(
      const ThreadStatusMsgPtr: PThreadStatusdMsg);

    procedure OnThreadQueryStarted(
      const ThreadQueryStartedMsgPtr: PThreadQueryStartMsg);

    procedure OnThreadQueryDone(
      const ThreadQueryDoneMsgPtr: PThreadQueryDoneMsg);

    procedure OnThreadQueryRecCount(
      const ThreadQueryRecCountMsgPtr: PThreadQueryRecCountMsg);
  public
    { Public-Deklarationen }
  protected
    procedure WndProc(var AMsg: TMessage); override;
  end;

var
  View: TView;

implementation

{$R *.dfm}

procedure TView.btnStartClick(Sender: TObject);
begin
  // I know this will leak at the moment!
  FSQLThrd := TSqlQueryThrd.Create(self.Handle, edtConStr.Text, edtSqlTxt.Text,
    VirtualTable1);
  try
    FSQLThrd.FreeOnTerminate := false;
    FSQLThrd.Start;
  except
  on E: Exception do
    MSGLog.Lines.Text := E.Message;
  end;
end;

procedure TView.FormDestroy(Sender: TObject);
begin
  if assigned(FSQLThrd) then
  begin
    FSQLThrd.Terminate;
    FSQLThrd.WaitFor;
    FSQLThrd.Free;
  end;
end;

procedure TView.OnThreadQueryStarted(
  const ThreadQueryStartedMsgPtr: PThreadQueryStartMsg);
begin
  case ThreadQueryStartedMsgPtr^.Running of
   true: QrPB.State := pbsNormal;
   false: QrPB.State := pbsPaused;
  end;
  Dispose(ThreadQueryStartedMsgPtr);
end;

procedure TView.OnThreadQueryDone(
  const ThreadQueryDoneMsgPtr: PThreadQueryDoneMsg);
begin
  case ThreadQueryDoneMsgPtr^.Done of
   true:
   begin
     QrPB.State := pbsPaused;
     try
       UniDataSource1.DataSet.DisableControls;
       UniDataSource1.DataSet := VirtualTable1;
       // exception
       // VCL.Graphics line 4197
       // EInvalidOperation: Canvas erlaubt kein zeichnen!
       DBGrid1.DataSource := UniDataSource1;
     finally
       UniDataSource1.DataSet.EnableControls;
     end;
   end;
   false: QrPB.State := pbsNormal;
  end;
   Dispose(ThreadQueryDoneMsgPtr);
end;

procedure TView.OnThreadStatusMsg(
  const ThreadStatusMsgPtr: PThreadStatusdMsg);
begin
  MSGLog.Lines.Add( string.Format('%s %s %s',
    [
     ThreadStatusMsgPtr^.ExecTime,
     ThreadStatusMsgPtr^.MessageStr,
     ThreadStatusMsgPtr^.SQLStr
    ]));
  Dispose(ThreadStatusMsgPtr);
end;

procedure TView.OnThreadQueryRecCount(
  const ThreadQueryRecCountMsgPtr: PThreadQueryRecCountMsg);
begin
  Statusbar1.Panels[0].Text := string.Format('RecCount: %s' ,
    [IntToStr(ThreadQueryRecCountMsgPtr^.ICount)]);
  Dispose(ThreadQueryRecCountMsgPtr);
end;

procedure TView.WndProc(var AMsg: TMessage);
begin
  with AMsg do
  begin
    case Msg of
      TS_THREAD_STATUS_AVAILABLE: OnThreadStatusMsg(
          PThreadStatusdMsg(WParam));

      TS_THREAD_QUERY_STARTED: OnThreadQueryStarted(
          PThreadQueryStartMsg(WParam));

      TS_THREAD_QUERY_DONE: OnThreadQueryDone(
          PThreadQueryDoneMsg(WParam));

      TS_THREAD_QUERY_COUNT: OnThreadQueryRecCount(
          PThreadQueryRecCountMsg(WParam));
    end;
  end;
  inherited;
end;

end.

Der Thread für die SQL Querys:

zusammenfalten · markieren

Delphi-Quellcode:

unit QueryThread;

interface

uses
  System.Classes,
  System.SysUtils,
  Winapi.Windows,
  Winapi.Messages,
  UniProvider,
  MySQLUniProvider,
  Data.DB,
  DBAccess,
  Uni,
  MemDS,
  MemData,
  VirtualTable;

// messages to be send to the main thread
const
  TS_THREAD_STATUS_AVAILABLE = WM_USER + 1;
  TS_THREAD_QUERY_STARTED = WM_USER +2;
  TS_THREAD_QUERY_DONE = WM_USER +3;
  TS_THREAD_QUERY_COUNT = WM_USER +4;

type
  TThreadStatusMsg = record
    MessageStr: string;
    SQLStr: string;
    ExecTime: String;
  end;
  PThreadStatusdMsg = ^TThreadStatusMsg;

  TThreadQueryStartMsg = record
    Running: Boolean;
  end;
  PThreadQueryStartMsg = ^TThreadQueryStartMsg;

  TThreadQueryDoneMsg = record
    Done: Boolean;
  end;
  PThreadQueryDoneMsg = ^TThreadQueryDoneMsg;

  TThreadQueryRecCountMsg = record
    ICount: Int64;
  end;
  PThreadQueryRecCountMsg = ^TThreadQueryRecCountMsg;

type
  TSqlQueryThrd = class(TThread)
  protected
    procedure Execute; override;
    procedure OnAfterFetchEvent(DataSet: TCustomDADataSet);
    procedure OnAfterOpen(DataSet: TDataSet);
  private
    FMainHandle: THandle;
    FSQLText: string;
    fStatusText: string;
    FUniDacConnection: TUniConnection;
    FUniDacSQLQuery: TUniQuery;
    FVirtualTable: TVirtualTable;

    ThreadStatusMsgPtr: PThreadStatusdMsg;
    ThreadQueryStartedMsgPtr: PThreadQueryStartMsg;
    ThreadQueryDoneMsgPtr: PThreadQueryDoneMsg;
    ThreadQueryRecCountMsgPtr: PThreadQueryRecCountMsg;

    function GetLongTime(aTime: TDatetime) : string;
  public
    constructor Create(aMainHandle: THandle; aConnectionStr: string;
      aSQL: string; aVTable: TVirtualTable); overload;
    destructor Destroy; override;

  end;

implementation

{ TSqlQueryThrd }

constructor TSqlQueryThrd.Create(aMainHandle: THandle;
  aConnectionStr, aSQL: string; aVTable: TVirtualTable);
begin
  inherited Create(True);
  
  // main thread handle
  FMainHandle := aMainHandle;

  FUniDacConnection := TUniConnection.Create(nil);
  FUniDacConnection.ProviderName := 'MySQL';
  FUniDacConnection.ConnectString := aConnectionStr;
  Assert(aConnectionStr <> '', 'Connection-String can not be empty!');

  // test if connection is successful otherwise goodbye
  try
    try
      FUniDacConnection.Connect;
    except
      terminate;
    end;
  finally
    // can be disconnected the unidac query established a connection by itself if needed
    FUniDacConnection.Disconnect;
  end;

  FSQLText := aSQL;
  Assert(FSQLText <> '', 'SQL-Text can not be empty!');

  FUniDacSQLQuery := TUniQuery.Create(nil);
  FUniDacSQLQuery.Connection := FUniDacConnection;
  FUniDacSQLQuery.FetchingAll;
  FUniDacSQLQuery.AfterFetch := OnAfterFetchEvent;
  FUniDacSQLQuery.AfterOpen := OnAfterOpen;
  FUniDacSQLQuery.SQL.Clear;
  FVirtualTable := aVTable;
end;

destructor TSqlQueryThrd.Destroy;
begin
  if FUniDacConnection.Connected then
    FUniDacConnection.Disconnect;
  FUniDacConnection.Free;
  FUniDacSQLQuery.Free;
  inherited Destroy;
end;

procedure TSqlQueryThrd.Execute;
begin
  NameThreadForDebugging('StormThread');

  FUniDacSQLQuery.SQL.Text := FSQLText;

  // send the main thread some messages...
  New(ThreadQueryStartedMsgPtr);
  ThreadQueryStartedMsgPtr^.Running := True;
  if not(PostMessage(FMainHandle, TS_THREAD_QUERY_STARTED,
    integer(ThreadQueryStartedMsgPtr), 0)) then
  begin
    Dispose(ThreadQueryStartedMsgPtr);
    terminate;
  end;

  New(ThreadStatusMsgPtr);
  ThreadStatusMsgPtr^.MessageStr := 'Status: Query started';
  ThreadStatusMsgPtr^.ExecTime := GetLongTime(Now);
  ThreadStatusMsgPtr^.SQLStr := '';
  if not(PostMessage(FMainHandle, TS_THREAD_STATUS_AVAILABLE,
    integer(ThreadStatusMsgPtr), 0)) then
  begin
    Dispose(ThreadStatusMsgPtr);
    terminate;
  end;

  try
    try
      FUniDacSQLQuery.Execute;

      // Must be set here otherwise the virtualtable in the main thread
      // does not contain any data!
      FVirtualTable.Assign(FUniDacSQLQuery);
    except
      FUniDacSQLQuery.Close;
      FUniDacConnection.Close;
      terminate;
    end;
  finally
    FUniDacSQLQuery.Close;
    FUniDacConnection.Disconnect;
    terminate;
  end;
end;

function TSqlQueryThrd.GetLongTime(aTime: TDatetime): string;
var
  formattedDate : string;
begin
  Result :='';
  try
    DateTimeToString(formattedDate, 'hh:nn:ss:zz', aTime);
  finally
    Result := FormattedDate;
  end;
end;

// special for unidac if that event is raised the query is done as written in the docu...
procedure TSqlQueryThrd.OnAfterFetchEvent(DataSet: TCustomDADataSet);
begin
  New(ThreadStatusMsgPtr);
  ThreadStatusMsgPtr^.MessageStr := 'Status: Query done';
  ThreadStatusMsgPtr^.ExecTime := GetLongTime(Now);
  ThreadStatusMsgPtr^.SQLStr := '// ' + FSQLText;
  if not(PostMessage(FMainHandle, TS_THREAD_STATUS_AVAILABLE,
    integer(ThreadStatusMsgPtr), 0)) then
  begin
    Dispose(ThreadStatusMsgPtr);
    terminate;
  end;

  New(ThreadQueryDoneMsgPtr);
  ThreadQueryDoneMsgPtr^.Done := True;
  if not(PostMessage(FMainHandle, TS_THREAD_QUERY_DONE,
    integer(ThreadQueryDoneMsgPtr), 0)) then
  begin
    Dispose(ThreadQueryDoneMsgPtr);
    terminate;
  end;
end;

// this event is raised when the record count is available
procedure TSqlQueryThrd.OnAfterOpen(DataSet: TDataSet);
begin
  New(ThreadQueryRecCountMsgPtr);
  ThreadQueryRecCountMsgPtr^.ICount := FUniDacSQLQuery.RecordCount;
  if not(PostMessage(FMainHandle, TS_THREAD_QUERY_COUNT,
    integer(ThreadQueryRecCountMsgPtr), 0)) then
  begin
    Dispose(ThreadQueryRecCountMsgPtr);
    terminate;
  end;
end;

end.

Was mir beim ersten Drüberschauen aufgefallen ist:

Du benutzt Postmessage d.h. es wird nicht gewartet bis die Nachrichten verarbeitet sind. Kann es dadurch zu Problemen kommen weil der VCL-Thread und dein Query-Thread gleichzeitig auf Sachen zugreifen?

Du rufst häufig Terminate auf, wertest aber Terminated nicht aus. Terminate beendet den Thread nicht sofort!

Zitat von CarlAshnikov:

Was mir beim ersten Drüberschauen aufgefallen ist:

Du benutzt Postmessage d.h. es wird nicht gewartet bis die Nachrichten verarbeitet sind. Kann es dadurch zu Problemen kommen weil der VCL-Thread und dein Query-Thread gleichzeitig auf Sachen zugreifen?

Du rufst häufig Terminate auf, wertest aber Terminated nicht aus. Terminate beendet den Thread nicht sofort!

Ja, und eventuell. Wegen dem Postmessage war mein Gedanke, dass nicht gewartet werden soll, da ich dachte das es so ggf. wieder zum Einfrieren der GUI kommen kann, denn dann hätte ich mir den seperaten Thread komplett sparen können oder Syncronize einsetzen können.

Ich kann wie gesagt mir das Problem im Moment selbst nicht erklären. Wegen dem Terminate geb ich Dir recht, dass ist so völliger Blödsinn.

P.s. Was mir noch einfällt, eigentlich sofern ich die Doku von Unidac richtig verstanden habe, greife ich erst dann auf Sachen zu bzw. weise diese zu wenn das Query fertig ist, also nicht vorher.
Lt. Doku ist dies der Fall wenn AfterFetch eintritt, siehe Thread.

Verstehe von dem Thema nicht wirklich was, aber was mich verwundert:

Wenn der Thread fertig ist, weist Du Datasource die VirtualTable zu und dem Grid dann DataSource.

Das kann ich nachvollziehen, allerdings hätte ich erwartet, dass vor dem Start des Thread eben gerade diese Verbindung aufgehoben wird.

Ich würd' hier also erwarten, dass nach dem ersten Threadstarten für die restliche Laufzeit des Programmes die Verbindung VirtualTable->DataSource->Grid bestehen bleibt.
Allerdings hatte ich die bisherige Anforderung so verstanden, dass eben genau das nicht der Fall sein soll.

Dashier verstehe ich nicht:

zusammenfalten · markieren

Delphi-Quellcode:

 try
    try
      FUniDacSQLQuery.Execute;

      // Must be set here otherwise the virtualtable in the main thread
      // does not contain any data!
      FVirtualTable.Assign(FUniDacSQLQuery);
    except
      FUniDacSQLQuery.Close;
      FUniDacConnection.Close;
      terminate;
    end;

Execute nimmt man bei 'ner Query doch eigentlich, wenn man keine Ergebnismenge erwartet, also bei Insert, Update ...
Müsste es bei 'nem Select noch Open heißen.
Bei 'nem Execute ist doch eigentlich auch kein Close erforderlich.
Oder ist das hier in diesem Zusammenhang anders?

Zitat von nahpets:

Verstehe von dem Thema nicht wirklich was, aber was mich verwundert:

Wenn der Thread fertig ist, weist Du Datasource die VirtualTable zu und dem Grid dann DataSource.

Das kann ich nachvollziehen, allerdings hätte ich erwartet, dass vor dem Start des Thread eben gerade diese Verbindung aufgehoben wird.

Ich würd' hier also erwarten, dass nach dem ersten Threadstarten für die restliche Laufzeit des Programmes die Verbindung VirtualTable->DataSource->Grid bestehen bleibt.
Allerdings hatte ich die bisherige Anforderung so verstanden, dass eben genau das nicht der Fall sein soll.

Dashier verstehe ich nicht:

zusammenfalten · markieren

Delphi-Quellcode:

 try
    try
      FUniDacSQLQuery.Execute;

      // Must be set here otherwise the virtualtable in the main thread
      // does not contain any data!
      FVirtualTable.Assign(FUniDacSQLQuery);
    except
      FUniDacSQLQuery.Close;
      FUniDacConnection.Close;
      terminate;
    end;

Execute nimmt man bei 'ner Query doch eigentlich, wenn man keine Ergebnismenge erwartet, also bei Insert, Update ...
Müsste es bei 'nem Select noch Open heißen.
Bei 'nem Execute ist doch eigentlich auch kein Close erforderlich.
Oder ist das hier in diesem Zusammenhang anders?

Ja da hast Du recht, dass mit dem Open bzw. Execute ist mir auch gerade aufgefallen, muss in dem Fall natürlich Open lauten. Danke für den Hinweis.

Zitat:

Das kann ich nachvollziehen, allerdings hätte ich erwartet, dass vor dem Start des Thread eben gerade diese Verbindung aufgehoben wird.

Das kann sollte ich vielleicht mal testen. Zumindest wäre das sinnvoll, Beim OnCreate des Formulars ist alles noch ungebunden, aber wenn der separate Thread gestartet wurde nicht mehr, ich ändere das mal ab.

Was mich noch interessieren würde:

Muss man die VirtualTable vor der Datenübernahme nicht schließen und nach der Zuweisung auf DataSource nicht öffnen?

Sprich: Bekommt man bei FVirtualTable.Assign(FUniDacSQLQuery); 'ne offene Datenmenge zurück?

zusammenfalten · markieren

Delphi-Quellcode:

procedure TView.btnStartClick(Sender: TObject);
begin
  UniDataSource1.DataSet.DisableControls;
  UniDataSource1.DataSet.Close;
  DBGrid1.DataSource := Nil;
  UniDataSource1.DataSet := Nil;
  // I know this will leak at the moment!
  FSQLThrd := TSqlQueryThrd.Create(self.Handle, edtConStr.Text, edtSqlTxt.Text, VirtualTable1);
  try
    FSQLThrd.FreeOnTerminate := false;
    FSQLThrd.Start;
  except
  on E: Exception do
    MSGLog.Lines.Text := E.Message;
  end;
end;

procedure TView.OnThreadQueryDone(
  const ThreadQueryDoneMsgPtr: PThreadQueryDoneMsg);
begin
  case ThreadQueryDoneMsgPtr^.Done of
   true:
   begin
     QrPB.State := pbsPaused;
     try
       UniDataSource1.DataSet.DisableControls;
       UniDataSource1.DataSet := VirtualTable1;
       DBGrid1.DataSource := UniDataSource1;
       UniDataSource1.DataSet.Open;
     finally
       // Das würd' ich nur machen, wenn's vorher keine Exception gab.
       UniDataSource1.DataSet.EnableControls;
     end;
   end;
   false: QrPB.State := pbsNormal;
  end;
   Dispose(ThreadQueryDoneMsgPtr);
end;

Zitat von stOrM:

Zitat:

Das kann ich nachvollziehen, allerdings hätte ich erwartet, dass vor dem Start des Thread eben gerade diese Verbindung aufgehoben wird.

Das kann sollte ich vielleicht mal testen. Zumindest wäre das sinnvoll, Beim OnCreate des Formulars ist alles noch ungebunden, aber wenn der separate Thread gestartet wurde nicht mehr, ich ändere das mal ab.

Das meinte ich mit

Zitat:

aber erst der Datasource zuweisen, wenn der Thread fertig ist, sonst versucht das grid die schon zu lesen während du sie noch befüllst.

Was wir immer machen ist auf den ButtonClick immer erstmal den Button abschalten (Enabled := False) und erst wieder anschalten, wenn wir fertig sind mit unserem Code.

Auch Dein RecordCount wird eventuell falsch sein, da UniQuery die Zahl anzeigt, die sie erstmal holen (default 25). Entweder musst Du QueryRecordCount property setzen (macht uniquery dann 2x das Query, einmal zum zählen und ein 2. Mal um die ersten Daten zu holen).
Ich empfehle einfach den RecordCount der VirtualTable nach dem Assign zu nutzen. Aber da beendest Du den Thread eh und du kannst im MainThread einfach den RecordCount der VT zu fragen.


@nahpets : ich glaube, es spielt keine Rolle, da VT eh das dataset schliessen muss um die Field Liste zu löschen, da die ja von DataSet übernommen wird. Und der VT sollte dann automatisch geöffnet werden. Aber das kann man ja überprüfen mit

markieren

Code:

If Not VT.State in dsBrowsing Then

Zitat von MyRealName:

Zitat von stOrM:

Zitat:

Das kann ich nachvollziehen, allerdings hätte ich erwartet, dass vor dem Start des Thread eben gerade diese Verbindung aufgehoben wird.

Das kann sollte ich vielleicht mal testen. Zumindest wäre das sinnvoll, Beim OnCreate des Formulars ist alles noch ungebunden, aber wenn der separate Thread gestartet wurde nicht mehr, ich ändere das mal ab.

Das meinte ich mit

Zitat:

aber erst der Datasource zuweisen, wenn der Thread fertig ist, sonst versucht das grid die schon zu lesen während du sie noch befüllst.

Was wir immer machen ist auf den ButtonClick immer erstmal den Button abschalten (Enabled := False) und erst wieder anschalten, wenn wir fertig sind mit unserem Code.

Auch Dein RecordCount wird eventuell falsch sein, da UniQuery die Zahl anzeigt, die sie erstmal holen (default 25). Entweder musst Du QueryRecordCount property setzen (macht uniquery dann 2x das Query, einmal zum zählen und ein 2. Mal um die ersten Daten zu holen).
Ich empfehle einfach den RecordCount der VirtualTable nach dem Assign zu nutzen. Aber da beendest Du den Thread eh und du kannst im MainThread einfach den RecordCount der VT zu fragen.


@nahpets : ich glaube, es spielt keine Rolle, da VT eh das dataset schliessen muss um die Field Liste zu löschen, da die ja von DataSet übernommen wird. Und der VT sollte dann automatisch geöffnet werden. Aber das kann man ja überprüfen mit

markieren

Code:

If Not VT.State in dsBrowsing Then

Ich hab die Änderungen jetzt soweit eingebaut, ändert aber nichts an der Fehlermeldung mit dem Canvas.
Teilweise bekomme ich sogar noch folgendes: VCL.Grids stop in Zeile 888 GridIndex ausserhalb des gültigen Bereichs (mal was neues)

Was den RecordCount angeht denke ich nicht das dieser falsch ist, ich setze beim Query explizit FetchAll also soll lt. Doku alles an Daten geholt werden und nicht nur partiell.

Zitat:

Ich empfehle einfach den RecordCount der VirtualTable nach dem Assign zu nutzen.

Wenn das funktionieren würde hätte ich das getan, deshalb der Umweg über die Messages. Der RecordCount im Main bei der VT ist nämlich immer 0 bei mir mit dem Query gehts einwandfrei.

Warum nimmst Du die Windows MessageQue und nicht System.Messaging?
Dann kannst Du dir auch das ganze Pointer-Zeug sparen.

Warum nimmst Du eine TThread Klasse und nicht System.Threading?

Eine eigene Threadklasse nutze ich nur noch, wenn ich den Thread 1x Erzeuge und behalte...
Zum Beispiel um mit einen SetEvent(StartEvent) die Verarbeitung in Nano-Sekundenbereich beginnen zu lassen. Zum Beispiel,
wenn von der Eingangsqueue ein neuer SQL-Befehlt kommt.

Vorgehen:
- Ich gebe die SQL-Befehle in die ThreadSaveQueue. Bei Eingang wir der Event gefeuert und der Thread läuft sofort los.
- ich kann jederzeit neue Befehle in die Queue feuern und die werden nacheinander abgearbeitet.
- Der Thread erzeugt die Daten und packt diese in einen Ausgang-Queue. Damit ist der Thread frei für weitere Aufgaben.
- Da ich der Eingangsqueue eine anonyme Procedure mitgegeben habe, kann die Ausgangsqueue in einem 2. Thread nach und nach die Syncronize der anonymen Proceduren aufrufen, die die Daten in der UI darstellen.

Natürlich kann man das über die System.Threading auch machen! Ich nutze jedoch eine TThread-Klasse, da ich hierüber den MultiThread-Zugriff auf eine SQLite Datenbank serialisiere!

Wenn ich mit MultiThread/MultiConnectionfähigen Datenbanken arbeite, nutze ich natürlich den ThreadPool, um so viele Anfragen wie möglich gleichzeitig zu handeln und die Skalierbarkeit des Datenbankservers auszunutzen.

Mavarik