> 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
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 ther
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 ab
[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 t
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.
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
n
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 */
7 matches
Mail list logo
