query.open blockiert

[brechi]

Habe mal SDAC (UniDAC) getestet, auch dort blockiert das "Open", selbst wenn FetchAll = False ist.
Weitere Vorschläge (am liebsten fuer ADO)

[EgonHugeist]

Hi brechi,

mit ADO selbst werden(soweit mir bekannt) immer alle geladen und konvertiert. Das TADORecorSet arbeitet grundsätlich mit einem full-fetch. All Daten werden via OLE-Variant bereit gestellt. Unglaubliche performance Bremse.

Zeos bietet dir auch den Zugriff über ntwdblib.dll (Protocoll: mssql) oder FreeTDS(diverse Versionen). Nativer Zugriff, jedoch ansi-basierend und bringt auch Tücken mit sich. Das TDS (tabular-data-stream) Protocol läßt keine NClob fetches ohne cast zu(der Grund für die OLE-DB Interpetation). Also schau mal ob du da mehr Erfolg hast und dies deinen Anforderungen entspricht... MSSQL selber ist a bisl, naja leistungsfähig ja, jedoch nur im reiner Forward-Only mode. Nahezu alle RDBM's, außer SQLite, lassen nachträgliches navigiern innerhalb der der Daten-Mengen zu. MSQQL jedoch in keiner Weise, (soweit mir bekannt -> Klärt mich auf und ich bau's ein). Jedoch lädt Zeos dann die Daten erst, wenn du eine weiter Zeile auslesen willst.

Werd jedoc mal reinschauen(ADO), ob da nicht doch irgendwie etwas zu ändern geht und evt. völlig falsch liege -> ADO.

Gruß, Michael

[jaenicke]

Ein ähnliches Problem habe ich gerade über DataSnap gelöst. Dort kommt dazu, dass ich nicht direkt an die Datenbank herankomme und ausschließlich (AFAIK) komplette DataSets bekomme.

Gelöst habe ich das indem ich mir (es ist ein MS SQL Server) mit DBCC SHOW_STATISTICS die Verteilung der Daten auf der Indexspalte abfrage und dann aus diesem Histogramm einen Abfrageplan erstelle, basierend auf den ermittelten statistischen Werten der aktuellen Verbindungsqualität usw.
Dann frage ich im Thread die einzelnen Pakete ab und hänge diese (in meinem Fall ist das am besten) synchronisiert in die Zieltabelle. Diese wiederum wird dann z.B. für die Anzeige in einer VirtualStringTree benutzt.

In deinem Fall würde es bei einem solchen Vorgehen reichen immer die Datasets mit den einzelnen Paketen weiterzureichen. Und du müsstest die Verarbeitung nicht einmal mit dem Hauptthread synchronisieren, sondern könntest diese auch gleich in Threads machen.

[brechi]

Hi, danke fuer eure Antworten.
Ich moechte ungern viel Zeit in die Umstellung der Abfragen investieren, zumal es mit AnyDAC ja auch ohne geht. (eventl. kauf ich die doch fuer mich und compiliere dann nur die finale Version damit).

Bisherige erstmal zufriedenstellende Funktion ist folgende:

Delphi-Quellcode:

    if (FQueryCount = 1) then
      Result.CursorLocation := clUseServer
    else
      Result.CursorLocation := clUseClient;
    if _ReadOnly then begin
      Result.ExecuteOptions := [eoAsyncFetch];
      Result.LockType := ltReadOnly;
    end;

cluseServer blockiert Open nicht, wird aber EXTREM langsam wenn dies innerhalb einer verschachtelten Funktion aufgerufen wird (2 offene Verbindungen ubder die Connection). eoAsyncFetch funktioniert mit cluseClient (Open blockiert nicht) ist aber trotzdem viel langsamer als clUseServer. Ggf. kann ich die Schleifen noch umstellen... Also moeglichst minimaler Aufwand, sonst kann ich gleich das ganze Programm umstellen

[tsteinmaurer]

Vielleicht ist es einfach auch nur das Problem, dass der Snapshot Isolation für READ COMMITTed Transaktionen per Default nicht aktiviert ist, d.h. dass dein lesender Zugriff durch eine noch nicht committete schreibende Transaktion blockiert ist.