access to sql statement

[mtissington]

Certainly for debugging and logging it would be very helpful to have access to the last sql statement either thru the database object or thru the exception handler ... like get_code() ... get_sql().

Is this possible?

[zauguin]

It might be helpful, but I do not think it is worth storing it if we only use it for debugging.
If we so not store it it is AFAICT only possible to get the SQL code of a prepared statement.
This might be useful, because we can get the expanded SQL, meaning the SQL with bound parameters inserted.

[mtissington]

I'm also using a sqlite swift lib for ios development too. It has the ability to access the sql and in my app I produce a log file. On numerous occasions having the sql has helped to track down errors.

fyi GRDB

[zauguin]

I think I do not really understand your usage. Do you use dynamically generated SQL queries? Do you use prepared statements?

[mtissington]

I'm using prepared statements.

[zauguin]

So could your problem be solved if the SQL could be extracted from the prepared statements?

[mtissington]

Not sure I understand your comment, first choice would be to have the expanded SQL available with parameters inserted as you say.

[zauguin]

I see three possible positions to expose the SQL code:

1. I understand your request in a way that you want a method of the database object to return he last executed command. I don't think this is possible without manual caching. If you want this, you may be able to inherit from sqlite::database and overload operator<< to cache the command, but I do not think this kind of caching should be done by default.
2. If you already have the object of a prepared statement and only want to get the code used to construct it (+bound parameters), that can be done. This information is provided by SQLite.
3. Additionally we can integrate the code of the statement into the sqlite_exception.

[mtissington]

2 and 3 sound great