Richard Hipp wrote:
This statement sets x to the string value "1", not the numeric value 1.
Try instead:
set x [expr 1]
My response:
In my actual program, not the cut-down example I gave, I set an amount
to be inserted into a numeric field the same way as I did in my
example, with a simple
set amount 12345
An insert query of the form
insert into <some table> (numeric_field) values (:amount)
Instead of using your solution, my approach will be to use a language
better matched to sqlite, rather than the mess that tcl has become,
where everything is a string, except maybe not quite, such as when you
do some hocus-pocus such as you proposed. It's been awhile since I've
written any tcl and I'd forgotten how bad it is. I tried it again
because I have the need for some scripts that talk to an existing
sqlite database and thought that, given the history of tcl and sqlite,
it would be a good fit. I was wrong.
But thanks for trying to help.
/Don
On Sun, Jan 26, 2014 at 11:33 AM, Donald Allen <donaldcal...@gmail.com> wrote:
> There's a several-year-old discussion of this issue here:
>
> http://wiki.tcl.tk/19627
>
> It looks like 'impedance mis-match' is an appropriate term for this
> and that the tcl/sqlite type relationship is problematic, due to the
> typelessness of tcl and the omission in the api of a way to indicate
> the type of the substitution. I'm going to use something other than
> tcl for what I'm doing.
>
> On Sun, Jan 26, 2014 at 10:37 AM, Donald Allen <donaldcal...@gmail.com> wrote:
>> This script
>>
>> #!/usr/bin/env tclsh
>>
>> package require sqlite3
>>
>> set x 1
>>
>> sqlite3 db /tmp/foo
>>
>> db eval {select (2 > :x) as foo} {
>> puts "foo was $foo"
>> }
>>
>> run on an up-to-date Arch Linux system produces
>>
>> foo was 0
>>
>> obviously incorrect. There seems to be an issue with variable
>> substitution here. Changing the line in question to
>>
>> db eval {select (2 > 1) as foo} {
>>
>> and re-running produces
>>
>> foo was 1
>>
>> obviously correct.
>>
>> The sqlite documentation on the tcl api says that variable
>> substitution can occur "in any position where it is legal to put a
>> string or number literal". There is no information in the
>> documentation about how to control this, so the api has to be deciding
>> for itself whether a string or numeric literal is appropriate and I
>> think it is getting it wrong here.
>>
>> db eval {select (2 > cast (:x as integer)) as foo} {
>>
>> works correctly.
>>
>> db eval {select (2 > '1') as foo} {
>>
>> produces
>>
>> foo was 0
>>
>> Looks like a bug to me, but perhaps I'm missing something. Comments?
>>
>> /Don Allen
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
