Re: [sqlite] Tcl variable substitution issue

I apologize for not replying directly to your messages. My account on this mailing list is not set up to send me individual messages. Richard Hipp wrote: You should do what you want, of course. But this statement is surprising since SQLite is really just a TCL extension that has "escaped" into

Re: [sqlite] Tcl variable substitution issue

On Sun, Jan 26, 2014 at 7:06 PM, Donald Allen wrote: > my approach will be to use a language > better matched to sqlite, > You should do what you want, of course. But this statement is surprising since SQLite is really just a TCL extension that has "escaped" into the

Re: [sqlite] Tcl variable substitution issue

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

Re: [sqlite] Tcl variable substitution issue

On Sun, Jan 26, 2014 at 10:37 AM, Donald Allen wrote: > This script > > #!/usr/bin/env tclsh > > package require sqlite3 > > set x 1 > This statement sets x to the string value "1", not the numeric value 1. Try instead: set x [expr 1] > > sqlite3 db /tmp/foo > >

Re: [sqlite] Tcl variable substitution issue

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

[sqlite] Tcl variable substitution issue

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.