TSQLDataSet, TSQLConnection Multithread Exception

[Barthiboy]

Hallo zusammen.
ich habe eine Anwendung geschrieben in der in einem Thread Daten via TCPIP von einem Server gelesen werden und in eine MSSQL Datenbank eingegraten werden.
Hierfür verwende ich TSQLDataSet, TSQLConnection
Beispiel:

Delphi-Quellcode:

  FSQLDataset.Close;
  FSQLDataset.CommandText := SQLCommand;
  FSQLDataset.ExecSQL(true);

funktioniert auch wunderbar.
Allerdings möchte ich jetzt im Main Thread (VCL) jetzt eine Anzahl der Datensätze aus der Tabelle ermitteln.
Hierfür habe ich wieder eine TSQLDataSet, TSQLConnection Komponente verwendet.
Somit eigentlich schön Threadsafe
Beispiel der abfrage

Delphi-Quellcode:

      SQLDS_Work.Close;
      SQLDS_Work.CommandText := 'SELECT COUNT(WareneingangsNr) from WEP02.dbo.WareneingangsNr WHERE Aktiv = 1';
      SQLDS_Work.Open;
      if SQLDS_Work.FieldCount > 0 then begin
        if SQLDS_Work.Fields[0].AsInteger > 1 then begin // Fehler weil mehrere Wareneingänge aktiv
          if Assigned(Logger) then begin
            Logger.LogErrorMessage('Es sind ' + IntToStr(SQLDS_Work.RecordCount) + ' Wareneingänge aktiv. Fehler bei Timer_Chart aufgetreten');
          end;
          Exit;
        end

und so weiter

wenn jeweils nur ein Thread läuft funktioniert es ohne Probleme.
Laufen beide knallts.
Aber warum?
Ich baue für jeden Thread eine extra Verbindung auf.
Eigentlich sollte eine MSSQL Datenbank doch so etwas können.
Es werden auch keine Objekte aus dem jeweils anderen Thread verwendet.

Danke für eure Hilfe

[quaero]

Zwei Datenverbindungen auf die gleiche Tabelle - davon ein schreibender Zugriff. Wird der lesende Zugriff da nicht ausgesperrt?

[baumina]

Zitat:

Zitat von Barthiboy (Beitrag 1323368)

Laufen beide knallts.

Darunter können wir uns jetzt echt viel vorstellen. Evtl. hast du dafür noch eine genauere Fehlerbeschreibung.

[Barthiboy]

Also ich bekomme eine Exception der Klasse $C00000005 mit der Meldung '$C00000005 ACCESS_VIOLATION'

Ich denke es gibt hier verschiedene Isolation Levels
https://msdn.microsoft.com/de-de/lib...=sql.120).aspx
Allerdings bei jeder Veränderung meinerseits, das gleiche Ergebnis

[baumina]

Mit solch spärlichen Informationen kann dir wahrscheinlich hier keiner helfen.

[Barthiboy]

dann wirst DU wohl oder übel doch einfach mal eine Frage stellen müssen.

Hier noch die DBXConfig.ini
DriverName=MSSQL
SchemaOverride=%.dbo
DriverUnit=Data.DBXMSSQL
DriverPackageLoader=TDBXDynalinkDriverLoader,DBXCo mmonDriver190.bpl
DriverAssemblyLoader=Borland.Data.TDBXDynalinkDriv erLoader,Borland.Data.DbxCommonDriver,Version=19.0 .0.0,Culture=neutral,PublicKeyToken=91d62ebb5b0d1b 1b
MetaDataPackageLoader=TDBXMsSqlMetaDataCommandFact ory,DbxMSSQLDriver190.bpl
MetaDataAssemblyLoader=Borland.Data.TDBXMsSqlMetaD ataCommandFactory,Borland.Data.DbxMSSQLDriver,Vers ion=19.0.0.0,Culture=neutral,PublicKeyToken=91d62e bb5b0d1b1b
LibraryName=dbxmss.dll
VendorLib=sqlncli10.dll
VendorLibWin64=sqlncli10.dll
HostName=DE01PCSF0799\AUT_SQL_SERVER
Database=WEP02
MaxBlobSize=-1
LocaleCode=0000
IsolationLevel=DirtyRead
OSAuthentication=False
PrepareSQL=True
User_Name=
Password=
BlobSize=-1
ErrorResourceFile=
OS Authentication=False
Prepare SQL=False

[baumina]

Du könntest z.B. debuggen und sagen wo welche Fehlermeldung auftaucht, oder du könntest den Quellcode des Threads zeigen, wo z.B. wie synchronisiert wird. Eine Zugriffsverletzung ist meist ein Hinweis auf einen Zugriff auf ein Objekt, das bereits freigegeben wurde, dass die SQL-Statements das auslösen ist recht unwahrscheinlich.

[Barthiboy]

Na das is doch mal eine Ansage.
Mach ich doch gleich so gut ich kann.

ich habe jetzt mit einem try-except endlich eine genauere Fehlerbeschreibung:
04.12.2015 11:19:27 Client : Exception = Zugriffsverletzung bei Adresse 000000000BB4768C in Modul 'dbxmss.dll'. Lesen von Adresse FFFFFFFFFFFFFFFF
04.12.2015 11:20:16 Client : Exception = Zugriffsverletzung bei Adresse 000000000BB47680 in Modul 'dbxmss.dll'. Lesen von Adresse 0000000000000082

Der Thread sieht in etwa so aus

Delphi-Quellcode:

        
if DataCount > 0 then begin
          // Daten einlesen
          SendStr := 'Worksation;' + FormatDateTime('yyyy.mm.dd hh-nn-ss', now) + ';' + IntToStr(SessionID) + ';FetchDataToTransmit##';
          FIdTCPClient.IOHandler.WriteLn(SendStr, nil);

          for j := 0 to Datacount - 1 do begin
            if not KommEnable then begin
              // Wenn der Benutzer die Kommunikation pausiert, hier warten bis es weiter geht!
              FIdTCPClient.Disconnect;
              Logged := false;
              break;
            end;
            for i := 0 to 21 do begin
              Count       := FIdTCPClient.IOHandler.ReadLongInt(false);
              RecStr      := FIdTCPClient.IOHandler.ReadString(Count, nil);
              Logger.LogMessage('Server : ' + RecStr);
              if DataExport  then begin
                SLStr       := SLStr + #9 + RecStr;
              end;
              Daten[i]    := RecStr;
              if i = 21 then begin
                if not DataNotInDB then begin  // doppelte Verneinung (;
                  if Produkt_Auswerten(Daten) < 0 then begin
                    KommEnable := false;
                  end
                end;
              end;
              RemainCount := Datacount - j - 1;
              // Wenn nichts abzuholen ist
              if RemainCount < 0 then RemainCount := 0;
              // Ack senden
              SendStr     := '1';
              Logger.LogMessage('Client : ' + SendStr);
              FIdTCPClient.IOHandler.Write(SendStr, nil);
            end;
            // Einen Datensatz komplett gelesen
            if DataExport then begin
              SLDaten.Add(SLStr);
              SLStr := '';
            end;
            if Terminated then begin
              Break;
            end;
          end;

Und Das updaten der Anzeige im Main wird von einem Timer getriggert und sieht dann so aus

Delphi-Quellcode:

  if SQLC_Work.Connected then begin
    try
      SQLDS_Work.Close;
      // Aktuellen Wareneingang ermitteln
      SQLDS_Work.Close;
      SQLDS_Work.CommandText := 'SELECT COUNT(WareneingangsNr) from WEP02.dbo.WareneingangsNr WHERE Aktiv = 1';
      SQLDS_Work.Open;
      if SQLDS_Work.FieldCount > 0 then begin
        if SQLDS_Work.Fields[0].AsInteger > 1 then begin // Fehler weil mehrere Wareneingänge aktiv
          if Assigned(Logger) then begin
            Logger.LogErrorMessage('Es sind ' + IntToStr(SQLDS_Work.RecordCount) + ' Wareneingänge aktiv. Fehler bei Timer_Chart aufgetreten');
          end;
          Exit;
        end
        else if SQLDS_Work.Fields[0].AsInteger = 0 then begin // Fehler weil kein Wareneingang aktiv
          Exit;
        end
        else if SQLDS_Work.Fields[0].AsInteger = 1 then begin
          SQLDS_Work.Close;
          SQLDS_Work.CommandText := 'SELECT [IdentNr], [WareneingangsNr] from WEP02.dbo.WareneingangsNr WHERE Aktiv = 1';
          SQLDS_Work.Open;
          if SQLDS_Work.FieldCount > 1 then begin
            IdentNr := SQLDS_Work.Fields[0].AsString;
            WENr := SQLDS_Work.Fields[1].AsString;
          end;
        end;
      end;
      IdentNrOrig := IdentNr;
      IdentNr := StringReplace(IdentNr, '-', '', [rfReplaceAll]);
      SQLDS_Work.Close;
      SQLDS_Work.CommandText := 'Select COUNT(Gesamtergebnis) from WEP02.dbo.Teil_' + IdentNr + ' WHERE Gesamtergebnis = 1';
      SQLDS_Work.Open;
      if SQLDS_Work.FieldCount > 0 then begin
        Gut := SQLDS_Work.Fields[0].AsInteger;
      end;
      SQLDS_Work.Close;
      SQLDS_Work.CommandText := 'Select COUNT(Gesamtergebnis) from WEP02.dbo.Teil_' + IdentNr + ' WHERE Gesamtergebnis = 0';
      SQLDS_Work.Open;
      if SQLDS_Work.FieldCount > 0 then begin
        Schlecht := SQLDS_Work.Fields[0].AsInteger;
      end;

      La_Wenummer.Caption.Text := WENr;
      La_Teilenummer.Caption.Text := IdentNr;

      SQLDS_Work.Close;
      SQLDS_Work.CommandText := 'Select (Teilename) from WEP02.dbo.Teile WHERE IdentNr = ' + quotedStr(IdentNrOrig);
      SQLDS_Work.Open;
      if SQLDS_Work.FieldCount > 0 then begin
        Teilename := SQLDS_Work.Fields[0].AsString;
        Delete(Teilename, 1, 4);
        if not TryStrToInt(Teilename, SelectedModell) then begin
          SelectedModell := 0;
        end;
      end;

Offensichtlich knallt es in der dbxmss.dll.
Allerdings wundert mich das, da ich gelesen habe das es bei multithreading keine Probleme gibt,
wenn jeder Thread seine eigene Connection hat.
Die Exceptions treten meistens auf wenn auf Fields[] zugegriffen wird

Danke

[nahpets]

Mehrere Vorschläge:
Fehler abfangen:

Delphi-Quellcode:

  SQLDS_Work.Close;
  SQLDS_Work.CommandText := 'Select (Teilename) from WEP02.dbo.Teile WHERE IdentNr = ' + quotedStr(IdentNrOrig);
  Try
    SQLDS_Work.Open;
    if SQLDS_Work.FieldCount > 0 then begin
      Teilename := SQLDS_Work.Fields[0].AsString;
      Delete(Teilename, 1, 4);
      if not TryStrToInt(Teilename, SelectedModell) then begin
        SelectedModell := 0;
      end;
    end;
  except
    on e : Exception do begin
      if Assigned(Logger) then begin
        Logger.LogErrorMessage(SQLDS_Work.CommandText);
        Logger.LogErrorMessage(e.Message);
      end;
    end;
  end;

Analog bei allen SQLDS_Work.Open einbauen.

Delphi-Quellcode:

        SQLDS_Work.Open;
        if SQLDS_Work.FieldCount > 0 then begin

ist gut und schön, aber was ist, wenn die Ergebnismenge (warum auch immer) leer ist?

Delphi-Quellcode:

  try
    SQLDS_Work.Open;
    if SQLDS_Work.Active then begin
      if not SQLDS_Work.Eof then begin
        if SQLDS_Work.FieldCount > 0 then begin
          ...
        end;
      end else begin
        if Assigned(Logger) then begin
          Logger.LogErrorMessage(SQLDS_Work.CommandText);
          Logger.LogErrorMessage('sinnvoller Text zur Fehlerbeschreibung (leere Ergebnismenge)...');
        end;
      end;
    end else begin
      if Assigned(Logger) then begin
        Logger.LogErrorMessage(SQLDS_Work.CommandText);
        Logger.LogErrorMessage('sinnvoller Text zur Fehlerbeschreibung (geschlossene Datenmenge) ...');
      end;
    end;
  except
    on e : Exception do begin
      if Assigned(Logger) then begin
        Logger.LogErrorMessage(SQLDS_Work.CommandText);
        Logger.LogErrorMessage(e.Message);
      end;
    end;
  end;

Diese Fehlerbeschreibung hilft nicht wirklich

Zitat:

Die Exceptions treten meistens auf wenn auf Fields[] zugegriffen wird

Da ja an mehreren Stellen auf Fields[] zugegriffen wird, passiert der Fehler bei irgendeinem der Fields[] oder bei einem Bestimmten und wenn bei einem Bestimmten, bei welchem?

Und wenn sie nicht bei Fields[] auftreten, wo denn dann bitte sonst noch?

Ist die Ergebnismenge der Abfrage leer, dürfte ein Zugriff auf Fields[] kaum funktionieren, da es ja keinen Datensatz in der Ergebnismenge gibt und damit FieldCount = 0 ist. Was ich momentan aber nicht weiß und beurteilen kann ist, ob ein Zugriff auf FieldsCount bei einer leeren Ergebnismenge möglich ist oder hier bereits ein Fehler auftreten kann.

1. Abfrage öffnen.
2. prüfen, ob Abfrage geöffent werden konnte.
3. wenn nein, Meldung ausgeben und abbrechen.
4. prüfen, ob Ergebnismenge leer ist.
5. wenn ja, Meldung ausgeben und abbrechen.
6. prüfen, ob Anzahl der erwarteten Felder in der Ergebnismenge vorhanden ist.
7. wenn nein, Meldung ausgeben und abbrechen.
8. Werte auslesen und verarbeiten.

Um alles herum per Try Except unerwartete Fehler abfangen und im Fehlerfalle Meldung ausgeben und abbrechen.

Abbrechen heißt hier: Entweder das Programm beenden oder in einem sicheren und konsistenten Zustand weiterarbeiten.

[quaero]

Warum sollte FieldCount nichts zurückliefern? Selbst bei

Code:

SELECT * FROM relation WHERE 1=0

werden alle Felder der Relation zurückgegeben. Und

Code:

SELECT COUNT(irgendwas) FROM relation

gibt immer auch einen Wert zurück. Selbst wenn kein Datensatz die Bedingung erfüllt oder relation leer ist, wird 0 zurückgeliefert.