Re: [sqlite] TCL API: substitution of NULL for non-existent variables

2019-02-28 Thread Donald Allen
error would occur at runtime. /Don > > > From: sqlite-users on behalf of Donald Allen > Sent: Thursday, February 28, 2019 08:35 AM > To: sqlite-users@mailinglists.sqlite.org > Subject: [sqlite] TCL API: substitution of NULL for non-existent variables > > Is there a way to

[sqlite] TCL API: substitution of NULL for non-existent variables

2019-02-28 Thread Donald Allen
Is there a way to override the substitution of NULL for non-existent Tcl variables in a query? I have been bitten by this many times, by mis-typing the variable name in the query and having the query do the wrong thing rather than failing outright. I think there ought to be an option that throws

Re: [sqlite] Tcl variable substitution issue

2014-01-27 Thread Donald Allen
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

2014-01-26 Thread Donald Allen
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 mi

Re: [sqlite] Tcl variable substitution issue

2014-01-26 Thread Donald Allen
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 /tm

[sqlite] Tcl variable substitution issue

2014-01-26 Thread Donald Allen
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.