Legacy applications should continue to work. You might get a
compiler warning about a type mismatch on the 2nd parameter to
sqlite3_trace(). But calling a 2-parameter function with 3
parameters is suppose to be harmless in C.
It's not allowed by the standard, so it will almost certainly
[EMAIL PROTECTED] wrote:
Please follow-up with criticisms or alternative approaches
for this idea. Thanks.
The biggest problem with the trace api is that there is no way to find
out what the bound parameters were. If an application follows best
practise using bound parameters all over then
DRH wrote:
Legacy applications should continue to work. You might get a
compiler warning about a type mismatch on the 2nd parameter to
sqlite3_trace(). But calling a 2-parameter function with 3
parameters is suppose to be harmless in C.
Harmless in C, but not so in other languages. I
Roger Binns wrote:
The biggest problem with the trace api is that there is no way to find
out what the bound parameters were. If an application follows best
practise using bound parameters all over then the trace api is rather
useless.
Thanks for bringing this up again. There was a thread about
The current interface definition for sqlite3_trace()
is as follows:
void *sqlite3_trace(
sqlite3 *db, /* Database connection */
void(*xTrace)(void*, const char*), /* Callback function */
void *pArg /* 1st arg to callback */
A suggestion, instead of using an integer code make it a bit mask so that any
and all permutataions of the defined events can be executed?
That way the tracing function can be installed, and the flag can be set to
disabled. Effectively disabling trace. Not sure if thats something useful or
Ken [EMAIL PROTECTED] wrote:
A suggestion, instead of using an integer code make it a bit mask so that
any and all permutataions of the defined events can be executed?
That way the tracing function can be installed, and the flag can be set to
disabled. Effectively disabling trace. Not
