On Mon, 2007-10-29 at 17:49 +0100, Ralf Junker wrote:
> >> I wonder if it is possible to retrieve bound host parameters from a
> >> prepared SQL statement? I am
> >> thinking of the opposite of the sqlite3_bind... family of functions like:
> >>
> >> int sqlite3_bound_int (sqlite3_stmt*, int*);
> >> int sqlite3_bound_double (sqlite3_stmt*, double*);
> >
> >You'd also need to specify the index of the ? parameter you're seeking.
>
> Certainly. Sorry for the ommission, glad you pointed this out.
>
> >> They would be usefull to work around the sqlite3_trace() limitation which
> >> does not replace host
> >> parameters in the SQL. With the sqlite3_bound... functions, the trace
> >> callback would be able
> >> retrieve the parameter values from the statement and replace them or log
> >> them separately.
> >
> >You could create all this functionality in your wrapper level above
> >the sqlite3 API.
> >
> >It would be easy enough for you to modify the sqlite3 sources to add
> >such functions to fish the values out of the internal Vdbe.aVar Mem
> >array of the sqlite3_stmt. If the type does not match what is stored
> >internally, or something was not previously bound or out of range, I
> >imagine an SQLITE_ERROR could be returned. Or maybe you want your
> >bound* functions to coerce the bound value to the type you specify.
>
> True, but we would need to access unsupported API to do so.
> And as we know only too well, unsupported API is subject to
> change without notice any time ;-). Therefore I would rather
> not write these myself but ask for the possibility to add them
> to the library officially, even if "experimental" only.
Depends how desperate you are. Say you want to query statement
object X that has 4 variables, you could do this:
pTmp = sqlite3_prepare("SELECT ?, ?, ?, ?");
sqlite3_transfer_bindings(X, pTmp);
/* Use sqlite3_step() etc. to fish values out of pTmp */
sqlite3_transfer_bindings(pTmp, X);
sqlite3_finalize(pTmp);
Dan.
>
> >Another complementary function, say sqlite3_bound_type, could
> >return the type(s) of the bound field. (I say types plural because
> >sometimes a value can be a combination of types at the same time -
> >i.e., MEM_Real|MEM_Int). These internal types would have to be
> >exposed if you required such functionality.
> >
> >#define MEM_Null 0x0001 /* Value is NULL */
> >#define MEM_Str 0x0002 /* Value is a string */
> >#define MEM_Int 0x0004 /* Value is an integer */
> >#define MEM_Real 0x0008 /* Value is a real number */
> >#define MEM_Blob 0x0010 /* Value is a BLOB */
>
> Indeed very much agreed to!
>
> Ralf
>
>
> -----------------------------------------------------------------------------
> To unsubscribe, send email to [EMAIL PROTECTED]
> -----------------------------------------------------------------------------
>
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
