Adoconnection mit Recordset direct, Einschränkungen ?

[hermannhass]

Hallo
ich habe heute ein paar Tests gefahren mit MS-Server und MySQL
Da ich viel Schnickschnack der ADO-Komponenten nicht gebrauche,
benutze ich zum Einlesen der Query-Daten nur das Recordset.
Dies kann man auch mit Adocommand und adoconnection direkt füllen.
Die sql-Befehle kann ich über ein Query/Command oder direkt
über die Connection ausführen.
Folgendes habe ich festgestellt:
Ich habe ca. 1000 sql-Befehle(egal op "select"/"Update"/"Insert") wie folgt ausgeführt:
Bei einem lokalen MS-SERVER (mein Haupteinsatzgebiet) ergab sich folgende Situation
(RemoteServer ohne grosse Differenzen):

Lokaler MS-SERVER
ADOCOMMAND mit gekoppelter ADOCONNECTION Zeitindex 1,0
ADOQUERY mit gekoppelter ADOCONNECTION Zeitindex 1,1-1,2
ADOCOMMAND mit eigener ADOCONNECTION via connectionstring Zeitindex 1,0
ADOQUERY mit eigener ADOCONNECTION via connectionstring Zeitindex 1,1
ADOCONNECTION alleine Zeitindex 0.5 !!!

Facit: SQL-Befehle direkt über die ADOCONNECTION abzusetzen ist fast doppelt so schnell
wie eine trivialer ADOCOMMAND!

Nun meine Frage?

Welche Einschränkungen könnte es hier geben, wenn ich alle nict parametrisierten SQL-Operationen
über eine (oder mehrere ADO-Connections) direkt mache? Selbst die Queries mit Ausgabe des recordsets laufen schneller...

[Bernhard Geyer]

Eine große Bremse ist die bestimmung der AutoInc-Felder in den ADOWrapper-Komponenten beim öffnen des Recorsets.
Habe selbst vor kurzen die letzten ADOExpress-Abhängigkeiten im Programm entfernt.

Und jeder Wrapper (hie ADOExpress/dbGO) ist prinzipbedingt immer eine Bremse.