Re: [sqlite] Bound parameters not working with prepared statement
On Fri, 2005-04-15 at 19:02 -0400, Clay Dowling wrote: > James Berry wrote: > > > It would be useful to use bound parameters in such cases. > > > > Might it make sense to coerce the value at runtime into a string > > value in such a case? I believe a similar restriction (ticket #1096: > > limit and offset) was recently lifted to allow bound parameters in > > those cases, where only an integer is allowed. > > In this case we're dealing with a bit of code that is probably not > frequently executed. snprintf is probably your friend here, at least > for the time being. > sqlite3_mprintf() with the %q parameter is perhaps more friendly still. -- D. Richard Hipp <[EMAIL PROTECTED]>
Re: [sqlite] Bound parameters not working with prepared statement
[16-04-2005 1:16, James Berry escreveu] I'm not the OP, but I'm simply suggesting that it would be, in general, really nice if the architecture could allow bound parameters for many more of these cases. Not to the point of keyword substitution (that would change meaning of a statement) but for any parameter. Yes, snprintf and friends can be used, but the ability to use bound parameters can really clean up code, and help also to separate SQL snippets from logic code. It's not a must have, but a nice nicety. I'm playing as the devil's lawyer here (this is right in English?), but you must remember bindable parameters are for pre-compiled statements so a lot of restrictions are in order here. By making the bindable parameter more flexible you will be slowing the performance of the execution, as it will have to make extra preparation before binding the values. (Hope I had it right, as I'm no sqlite expert) Regards, ~Nuno Lucas
Re: [sqlite] Bound parameters not working with prepared statement
On Apr 15, 2005, at 4:02 PM, Clay Dowling wrote: James Berry wrote: It would be useful to use bound parameters in such cases. Might it make sense to coerce the value at runtime into a string value in such a case? I believe a similar restriction (ticket #1096: limit and offset) was recently lifted to allow bound parameters in those cases, where only an integer is allowed. In this case we're dealing with a bit of code that is probably not frequently executed. snprintf is probably your friend here, at least for the time being. I'm not the OP, but I'm simply suggesting that it would be, in general, really nice if the architecture could allow bound parameters for many more of these cases. Not to the point of keyword substitution (that would change meaning of a statement) but for any parameter. Yes, snprintf and friends can be used, but the ability to use bound parameters can really clean up code, and help also to separate SQL snippets from logic code. It's not a must have, but a nice nicety. -jdb
Re: [sqlite] Bound parameters not working with prepared statement
James Berry wrote: It would be useful to use bound parameters in such cases. Might it make sense to coerce the value at runtime into a string value in such a case? I believe a similar restriction (ticket #1096: limit and offset) was recently lifted to allow bound parameters in those cases, where only an integer is allowed. In this case we're dealing with a bit of code that is probably not frequently executed. snprintf is probably your friend here, at least for the time being. Clay
Re: [sqlite] Bound parameters not working with prepared statement
I believe that exactly the right circumstances to allow bound parameters is all of the same places where literal values are allowed, namely strings, numbers, nulls, etc. It does not make sense to have bound parameters in any other situation. -- Darren Duncan
Re: [sqlite] Bound parameters not working with prepared statement
On Apr 15, 2005, at 4:16 PM, D. Richard Hipp wrote: On Fri, 2005-04-15 at 15:49 -0700, Cory Nelson wrote: It seems when a bind a string to "attach ? as dbname", it is never translated into the final statement. Is this supposed to happen? SQLite only allows bound parameters in places where it is legal to put an expression. Remember that bound parameters can be filled in with NULL, integers, floating point numbers, or strings. And so bound parameters can only be used in places were all those values are legal options. You can not use a floating point number, an integer, or a NULL as the name of a database file in an ATTACH statement - that would make no sense. Hence, bound parameters are not allowed in that context. It would be useful to use bound parameters in such cases. Might it make sense to coerce the value at runtime into a string value in such a case? I believe a similar restriction (ticket #1096: limit and offset) was recently lifted to allow bound parameters in those cases, where only an integer is allowed. -jdb
Re: [sqlite] Bound parameters not working with prepared statement
On Fri, 2005-04-15 at 15:49 -0700, Cory Nelson wrote: > It seems when a bind a string to "attach ? as dbname", it is never > translated into the final statement. Is this supposed to happen? > SQLite only allows bound parameters in places where it is legal to put an expression. Remember that bound parameters can be filled in with NULL, integers, floating point numbers, or strings. And so bound parameters can only be used in places were all those values are legal options. You can not use a floating point number, an integer, or a NULL as the name of a database file in an ATTACH statement - that would make no sense. Hence, bound parameters are not allowed in that context. -- D. Richard Hipp <[EMAIL PROTECTED]>
[sqlite] Bound parameters not working with prepared statement
It seems when a bind a string to "attach ? as dbname", it is never translated into the final statement. Is this supposed to happen? -- Cory Nelson http://www.int64.org
