System.Data.SQLite

Is it possible for your wrapper to include the SQL statement that was being run in the exception that gets thrown?  This would definately make it easier to know what the system was trying to do when things started to break.  For basic syntax errors, it makes it easy to spot without trying to reproduce the error, and for other errors the SQL would give an idea of where in a process things died.

It's not always possible, but I'll look into it.

Robert

 

Much appreciated. Thanks.

This would defintily be helpful

I second that request! Maybe add it to Exception.Data?

Definitely helpful, but if you're a consumer of the SQLite ADO library, make sure that you've evaluated the security surrounding this.

For example... you wouldn't want a web app to dump the SQL statement back to the user (which would give hackers an idea of the schema of your db). This *shouldn't* be a problem with production apps (as errors should be replaced by a generic "whoops!" page), but there's a big difference between *should* and is!

Just a thought.

Trev

A very good point indeed. A feature limited to Debug builds? If at all.

security issues for this are big.  I'd turn it off by default and then have it configurable via a connection string parameter (which also makes it fully backwards compatible).

In my own apps I always funnel all sql calls through my own wrapper and I do include sql in the message, but it's also my app and not a component and I know I never show users the raw error message.  :-)

Sam