Neiiin.
Dieter und ich überlegen halt gerne wie wir das Forum vollquatschen können.
In manchen Punkten unterscheiden wir uns in den Meinungen was aber, denke ich, keine Diskrepanz in der Qualifikation ist.

Die Frage des Timeouts ist ggf. wirklich ein Problem.
Mache ich einen "insert ... select ...", kann dieser bei einer großen Tabelle durchaus mal mehrere Minuten dauern. Habe ich nun einen Default-Timeout von 30 Sekunden, würde dieser SQL grundsätzlich abbrechen.
Auf der AS/400 wird aber nur die Select-Phase auf potentiellen Timeout vor dem 1. Satz geprüft. Der eigentliche SQL darf dann durchaus ewig dauern.
Bei anderen DB's mag das unterschiedlich gehandelt werden.
Wobei ich hier bei einem SQL-Server durchaus bei einem Update von 100.000 Sätzen schon mal 10-15 Minuten gewartet habe. Ein Timeout hat da nicht zugeschlagen.

Deswegen noch mal die Frage von vorhin:
Bei welchem SQL ist denn ein Timout gefragt?
Ist es tatsächlich nur der "Select", dann wäre der Querytimeout eigentlich ausreichend, da ich mittels Resultset (Reader) ja dann selber bestimme, wie lange ich denn nun Daten empfangen will.

Ansonsten heißt ja "Query-Timeout" eigentlich wirklich "Select"-Timeout.
Wobei beim ADODB.Command das wieder "CommandTimeout" heißt und wir wieder beim Update/Delete sind.

Ach ja: Der Querytimeout zieht auch beim SQL-CALL. Zumindest konnte ich das schon mal feststellen, da mein SQL-Wrapper auf OPM-Programme da schon mal gecancelt wurde.