See the question and my original answer on StackOverflow

The CodeFluent Runtime handles database connection automatically, per thread. The main benefit is to not worry about managing connections, so you can do this with a "customer" generated class:

Customer customer = new Customer();
customer.Name = "Joe"
customer.Save();

and you never used a connection object nor a connection string because they're configured and are ambient. 10 years ago when the product was created, people were not very used to the using statement (and it did not even existed for VB.NET). Under the hood, a connection is of course opened, and never closed. It's rather similar to what the ADO.NET pool does in fact.

You shouldn't need to use the closeConnectionOnCompleteCommand parameter if all the runtime execution chain (ADO connection pool max size, IIS max thread per processor, database server max connection, etc.) is configured consistently.

For example if you have 100 max connection in the pool and 10 max connections in SQL server, that's not consistent, because at one moment in time, you may have more connections in the pool that the SQL Server will accept and you will get exceptions from SQL server.

Historically, that error happened only seldom, because a server like IIS prior to version 7 (or maybe it's Windows or .NET that changed how it really works) did not really "rotated" threads in the pool (you'd get only the same few threads). Now since IIS 7, threads are changing all the time for some reason, and so connections will be created automatically more rapidly and not closed by default (one per thread per default). So you would get that error more often. The first solution was to make sure every "max" is configured consistently. The second solution was to add that closeConnectionOnCompleteCommand parameter and make life easier for everyone.