SQLite Forum

SQLite .NET: CommandBuilder performs really bad on tables with a lot of indexes
Login
>That cannot possibly be true. 

But it is the truth.

>An empty database will open instantaneously, no matter the host language.

Also true. And the code above confirms that also:

The code above explained:

- Create a completly NEW database

- Create the "TestTable"

- Add ColumnPK / Integer / primary key 

- Add Column001 to Column900 / Integer

- Add 45 indexes

> Upto DataAdapter Select: 0s

All these steps and also executing "SELECT * FROM TestTable;" executes nearly instantaneously without any problem. Also adding, deleting or updating commands will be executed in an acceptable time (but the code above doesn't do any operations, because that works without a problem).

But: With Ado.net it is usual to create the needed SQL commands for delete/insert/update out of the select command. Thatfor the CommandBuilder class exists. And exactly the call to generate an command burns the 40 seconds.

Meanwhile I took a deeper look into the internal source code of SQLiteCommandBuilder. The CommandBuilder executes the "SELECT * FROM TestTable;"-statement with the "SchemaOnly" and "KeyInfo"-option. The following call to "SQLite.DbDataReader.GetSchemaTable" takes 40 seconds. Currently I can't say, which statements are executed in there, but there are some nested selection-loops inside to collect the schematable.

(Please note again: I am talking about the SQLite dotnet API ["System.Data.SQLite Downloads" from this page](http://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki") )

>If one of us simply creates a test database with our own bright ideas of what these hundreds of tables and indices look like, and it performs fine, then we've spent a lot of effort to prove nothing.

Also correct - because you would test the road and the problem isn't the road.
The time wasting occures in the "SQLite to ADO.NET"-layer (car). And that's why the detailed schema doesn't bother.
I don't know anymore, how I could explain it better.