[ecosSystem]

The RDD had no way to set the timeout of its statements, so every statement ran with the provider default (30 seconds for SQL Server). On large tables some statements take longer: creating an index on a table with millions of rows, a count, or an import. They were cancelled after 30 seconds and reported like any other error, which for a read means no rows.

What changed

• New connection property and connection string option CommandTimeout: the time in seconds a statement may run before it is cancelled. 0 means no limit; the default -1 keeps the provider default, so nothing changes unless it is set.
• SqlDbCommand applies it to the ADO.NET command before every execution (ExecuteReader, ExecuteScalar, ExecuteNonQuery, GetSchemaTable).

Server=...;Initial Catalog=...;CommandTimeout=300

or at run time, e.g. for a maintenance step:

var nTimeout := oConn:CommandTimeout
oConn:CommandTimeout := 0
// ... create indexes, import ...
oConn:CommandTimeout := nTimeout

Testing

Our ERP has used it since moving a customer dataset (72 GB, tables with up to 14 million rows) to SQL Server: the connection gets CommandTimeout from its configuration, and the synchronisation at program start (import of the DBF data, creating and rebuilding indexes) runs with 0. The import (more than two hours, single CREATE INDEX statements of several minutes) and a rebuild of 316 indexes (20 minutes) ran without timeouts. Without the option set, the behaviour is unchanged.

🤖 Generated with Claude Code