Settings.CommandTimeout

Settings.CommandTimeout and Settings.IncludeQueryTraceOn9481Flag

The two settings for when reading your schema is slow or appears to hang.


	`Settings.CommandTimeout`	`Settings.IncludeQueryTraceOn9481Flag`
Type	`int` (seconds)	`bool`
Default	`600`	`false`
Databases	All	SQL Server only
In `Database.tt`?	Yes	Yes

Settings.CommandTimeout

How long the efrpg tool waits for each schema query before giving up. 0 waits indefinitely.

Ten minutes sounds generous and occasionally is not. Reading a schema is a lot of queries against system tables, and on a large database with stale statistics some of them are slow - see below.

Settings.CommandTimeout = 1200; // 20 minutes
Settings.CommandTimeout = 0;    // No limit

Raising it treats the symptom. If you need more than ten minutes, something is wrong, and the two fixes below are worth trying first. Use 0 only while diagnosing - a template that hangs forever is worse than one that fails.

This is the design-time timeout. It has nothing to do with the timeout your application uses at run time, which you set on the DbContext.

Settings.IncludeQueryTraceOn9481Flag

Adds OPTION (QUERYTRACEON 9481) to the schema queries, forcing SQL Server to use the pre-2014 cardinality estimator.

This is for one specific, real problem: on SQL Server 2014, a change to the cardinality estimator could produce a catastrophic plan for the metadata queries, turning a two-second read into an apparent hang. If you are on 2014 and saving the .tt seems to freeze, this is the setting.

It needs elevated privileges - QUERYTRACEON requires ALTER TRACE or sysadmin - which is why it is off by default.

If you are not on SQL Server 2014, leave it alone.

What to try first, in order

1. Turn off stored procedures. On SQL Server, discovering what a procedure returns means executing it under SET FMTONLY ON, once per procedure. On a database with hundreds of procedures this is almost always the entire runtime:

FilterSettings.IncludeStoredProcedures      = false;
FilterSettings.IncludeTableValuedFunctions  = false;
FilterSettings.IncludeScalarValuedFunctions = false;

2. Update the statistics on the system tables. A well-documented SQL Server problem with a fix that takes seconds - see Speed up Reverse generating.

3. Filter down to the tables you need. Fewer tables is less to read, and a DbContext with 40 entities also builds its model faster at run time than one with 900. See Filtering.

4. Only then raise the timeout.

Gotchas

CommandTimeout is per query, not for the whole run. A generation that takes twenty minutes across two hundred queries never trips a ten-minute timeout.

A timeout surfaces as a partial result, not a crash. Each read is wrapped, so a failure is recorded as an error in the payload and the tool exits with code 2. You get generated code missing whatever failed to read, with the error as a comment - which is easy to miss.

QUERYTRACEON fails without permission, and the failure is the schema read failing, not a clear message about privileges.

Neither setting affects the generated code. They are both about the design-time read.

Settings.CommandTimeout

Settings.CommandTimeout and Settings.IncludeQueryTraceOn9481Flag