Robert Simpson wrote:
This is one gives me pause. I see lots of people doing things like
this in their code (Using C# since I address this in my wrapper's
helpfile and its convenient):
using (SQLiteCommand mycommand = new SQLiteCommand(myconnection))
{
int n;
for (n = 0; n < 100000; n ++)
{
mycommand.CommandText = String.Format("INSERT INTO [MyTable]
([MyId]) VALUES({0})", n + 1);
mycommand.ExecuteNonQuery();
}
}
I try to discourage this sort of thing, but so many people do this and
they'll be hit with a stiffer penalty under the proposed change.
IMO schema change errors are an outside case, and preventing them by
introducing this change would only penalize users that have already
either coded around this issue or don't experience it at all.
Robert,
I don't understand why you think your users will pay a stiffer penalty
under the proposed change. In your case the database schema isn't
changing, so there will be no SQLITE_SCHEMA errors to handle. The only
cost is the cost of storing a copy of the SQL string for the lifetime of
the prepared statement. In your case I assume that the statement is
prepared, stepped, and finalized in your ExecuteNonQuery function. So it
would only require additional memory for one copy of the SQL string for
the length of time that that function takes to execute. That storage
would be released when the prepared statement is finalized. I don't
think this is a severe penalty for any user.
Dennis Cote
