FireDAC macht unendlich viele Fetches

[OlafSt]

Hallo Freunde,

heute ein Mysterium. Ein simples Delphi-Programm (10.2 Tokyo) mit FireDAC. Man nehme eine normale TFDConnection, binde den SQL-Server via "Microsoft ODBC Driver 17 for MSSQL" ein, hänge eine einfache TFDQuery dran und verpasse letzterer ein einfaches Statement: "SELECT * FROM Orte ORDER BY StatOrt". Ein * geht hier in Ordnung, werden eh alle Felder abgefragt.

Die Tabelle hat etwa 30k Einträge, also kein Hexenwerk. Auf unserem internen SQL-Server generiert FireDAC dabei so um die 200 EXEC-Statements, bis alles so weit abgeholt ist.

Nun haben wir bei einem Kundensystem ein Phänomen, bei dem die Anzahl der Exec's regelrecht explodiert, auf >120.000 statt 200. Es ist immer dieselbe Abfolge pro Datensatz:

Code:

declare @p1 int
set @p1=1073741826
declare @p2 int
set @p2=180150009
declare @p5 int
set @p5=8
declare @p6 int
set @p6=1
declare @p7 int
set @p7=11130
exec sp_cursorprepexec @p1 output,@p2 output,NULL,N'SELECT * FROM Orte ORDER BY StatOrt',@p5 output,@p6 output,@p7 output
select @p1, @p2, @p5, @p6, @p7

Dieses Statement ist das SELECT. Es folgt nun:

Code:

exec sp_cursoroption 180150009,1,24
exec sp_cursoroption 180150009,1,25
exec sp_cursorfetch 180150009,2,1,50
exec sp_cursoroption 180150009,3,24
exec sp_cursor 180150009,40,1
-- ab hier repeat
exec sp_cursoroption 180150009,1,24
exec sp_cursoroption 180150009,3,25  -- die 3 ist anders
exec sp_cursor 180150009,40,1 --die 1 ist wohl der Datensatz
exec sp_cursoroption 180150009,1,25
exec sp_cursor 180150009,40,1
exec sp_cursor 180150009,40,1
exec sp_cursor 180150009,40,1
exec sp_cursor 180150009,40,1
exec sp_cursor 180150009,40,1
exec sp_cursoroption 180150009,3,24
exec sp_cursor 180150009,40,2  -- die 2 ist anders
...
...
...

Und diese Kette an Execs für jeden einzelnen Datensatz. Das belastet den Server ganz enorm und das Starten der Anwendung dauert statt eines Wimpernschlags ne geschlagene Minute.

Hat jemand eine Ahnung, was da am SQL-Server umgestellt werden müsste ?

[hoika]

Hallo,

Zitat:

Die Tabelle hat etwa 30k Einträge, also kein Hexenwerk. Auf unserem internen SQL-Server generiert FireDAC dabei so um die 200 EXEC-Statements, bis alles so weit abgeholt ist.

1. Und bei Eurem Server sind auch 30.000 Datensätze drin?

2. Ist euer interner Server der gleiche wie beim Kunden? (Versionsnummer usw.)

3. Ist die Query wirklich separat oder hängt da noch was dahinter (TDBGrid oder so).

4. Warum nehmt ihr ODBC statt ADO?

[OlafSt]

Zitat von hoika:

Hallo,
1. Und bei Eurem Server sind auch 30.000 Datensätze drin?

2. Ist euer interner Server der gleiche wie beim Kunden? (Versionsnummer usw.)

3. Ist die Query wirklich separat oder hängt da noch was dahinter (TDBGrid oder so).

4. Warum nehmt ihr ODBC statt ADO?

1. Ja. Ist eine Kopie der Datenbank.
2. Ja, gleiche BD verwendet, nur anderer Lizenzcode
3. Ist wirklich separat.
4. Weil Microsoft ADO und Native SQL abgekündigt hat und ODBC nun "the new holy grail" ist. Ich weiß, das war schon mal so und wird sich auch wieder ändern.

[hoika]

Hallo,
OK, zu Punkt 4 hast du da Infos?

Ich würde da trotzdem testweise mal eine AdoQuery drüberlaufen lassen.

Was mir noch einfällt wäre UniDirectional auf True setzen, falls es das Property dort gibt.


Ich denke übrigens nicht, dass es mit Server-Einstellungen zu tun hat,
sondern auf der Client-Seite etwas falsch/vermurkst eingestellt ist.

[jobo]

Also wenn keine Subquery und kein datensensitives Delphi Element dranhängt, dann ist es merkwürdig.

Was mir einfällt, wäre evtl. ein Collation Problem wegen des Order By. Der Client hat vielleicht ein schräges Ländersetting.
Ich würde auf jedenfall sicherstellen, dass ein definierter Installationsablauf (DbClient/ODBC) auf einem Testgerät erfolgt.

[HolgerX]

Hmm..

zu Punkt 4:
Nicht ganz richtig!!

Zwar sind der alte SQLOLDDB und die Native OLEs abgekündigt, jedoch gibt es seitens MS seit 2017 einen aktuellen OLE Treiber:

https://www.microsoft.com/de-de/down....aspx?id=56730

Dieser wird auch weiter entwickelt.


Quelle:
https://docs.microsoft.com/de-de/sql...l-server-ver15

[OlafSt]

So, ich habe mal das ganze auf den SQL Native umgestellt.

Der Effekt ist dann wie weggeblasen. Muss es also etwas sein, mit dem ODBC nicht so 100% klar kommt.

[hoika]

Hallo,
vielleicht ist bei den ODBC-Einstellungen irgendwas mit den lokalem Cache vermurkst worden.

[Sinspin]

Hallo. Danke fürs posten der Lösung.
Ich habe mit ODBC und MSSQL Server schon was ähnliches erlebt. Allerdings nur wenn man die gleiche Abfrage in der gleichen Query nochmal ausführt. Aus irgend einem Grund verdoppelt sich dann mit jedem Aufruf das übertragene Datenvolumen. Ich verwende da UniDac. DevArt meinte dazu das es an ODBC/ SQL Server liegt und man da nix machen kann. ...würde mich doch aber sehr wundern.

[Uwe Raabe]

Zitat von OlafSt:

4. Weil Microsoft ADO und Native SQL abgekündigt hat und ODBC nun "the new holy grail" ist. Ich weiß, das war schon mal so und wird sich auch wieder ändern.

Das ist nicht ganz richtig. Der aktuell empfohlene Weg ist Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL) (siehe Microsoft OLE DB Driver for SQL Server), nicht zu verwechseln mit dem alten Microsoft OLE DB Provider for SQL Server (SQLOLEDB).

Der Microsoft ODBC Driver for SQL Server ist wieder was anderes.