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 von Barthiboy:

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.