Re: [sqlite] Upgrade from 3.4.2 to 3.5.9 breaks Tcl code
D. Richard Hipp wrote: > On Jun 13, 2008, at 12:22 AM, Jeff Godfrey wrote: > >> Thanks for the quick solution. I've adjusted my code accordingly. >> So, >> do you consider this a buglet or more just the closing of a gap that >> shouldn't have existed in the first place? > The column naming algorithm for results > without an AS clause has changed in the past and will probably change > again in the future. So make no assumptions. Always use an AS clause. > Noted for future reference, and code (re)adjusted... ;^) Thanks, Jeff ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Upgrade from 3.4.2 to 3.5.9 breaks Tcl code
On Jun 13, 2008, at 12:22 AM, Jeff Godfrey wrote: >> > Thanks for the quick solution. I've adjusted my code accordingly. > So, > do you consider this a buglet or more just the closing of a gap that > shouldn't have existed in the first place? It's interesting that the > original code works outside of a proc in 3.5.9, but not inside... > The TCL interface assigns values to variables where the name of the variable is the "column name" in the result set. But SQLite makes no promises about what a column name is going to be unless you use an "AS" clause on each column. The column naming algorithm for results without an AS clause has changed in the past and will probably change again in the future. So make no assumptions. Always use an AS clause. D. Richard Hipp [EMAIL PROTECTED] ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Upgrade from 3.4.2 to 3.5.9 breaks Tcl code
D. Richard Hipp wrote:
> On Jun 12, 2008, at 11:08 PM, Jeff Godfrey wrote:
>
>> dbMem eval {select distinct(owner) from lockinfo order by owner} {
>>
>> }
>>
>> That works correctly in my original app using 3.4.2, but complains
>> that
>> there is no such variable "owner" when using 3.5.9.
>>
>
> Solution 1:
>
>dbMem eval {SELECT DISTINCT owner FROM lockinfo ORDER BY owner} {
> puts $owner
>}
>
> Solution 2:
>
>dbMem eval {SELECT DISTINCT(owner) AS owner FROM lockinfo ORDER BY
> owner} {
>puts $owner
>}
>
> Solution 3:
>
>dbMem eval {SELECT DISTINCT(owner) FROM lockinfo ORDER BY owner} {
> puts ${(owner)}
>}
>
Thanks for the quick solution. I've adjusted my code accordingly. So,
do you consider this a buglet or more just the closing of a gap that
shouldn't have existed in the first place? It's interesting that the
original code works outside of a proc in 3.5.9, but not inside...
Again - thanks.
Jeff
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Upgrade from 3.4.2 to 3.5.9 breaks Tcl code
On Jun 12, 2008, at 11:08 PM, Jeff Godfrey wrote:
>
> dbMem eval {select distinct(owner) from lockinfo order by owner} {
>
> }
>
> That works correctly in my original app using 3.4.2, but complains
> that
> there is no such variable "owner" when using 3.5.9.
Solution 1:
dbMem eval {SELECT DISTINCT owner FROM lockinfo ORDER BY owner} {
puts $owner
}
Solution 2:
dbMem eval {SELECT DISTINCT(owner) AS owner FROM lockinfo ORDER BY
owner} {
puts $owner
}
Solution 3:
dbMem eval {SELECT DISTINCT(owner) FROM lockinfo ORDER BY owner} {
puts ${(owner)}
}
D. Richard Hipp
[EMAIL PROTECTED]
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Upgrade from 3.4.2 to 3.5.9 breaks Tcl code
Hm... I sent this message last night as a non-list member. I
received a notification that it would need to be approved by a moderator
before being made public. About 15 hours later, I received a "Post was
rejected... No reason given" message. Why's that? So now I'm
subscribed again. Anyway...
==
Hi All,
I am upgrading a Tcl/SQLite based application from SQLite 3.4.2 to
SQLite 3.5.9. I'll mention that I'm also upgrading from Tcl 8.4.19 to
Tcl 8.5.2 in case it's relevant, though both versions of Tcl behave the
same when using SQLite 3.5.9.
Anyway, I have a number of procedures that operate like the following:
dbMem eval {select distinct(owner) from lockinfo order by owner} {
}
That works correctly in my original app using 3.4.2, but complains that
there is no such variable "owner" when using 3.5.9. Interestingly, I've
found that the above code works under 3.5.2 when not inside a Tcl
procedure. Inside the procedure though, it breaks as described. Also,
a few other variations...
Inside a procedure, using 3.5.2, replacing "distinct(owner)" with just
"owner" works correctly and replacing "distinct(owner) with just "*"
works correctly, though neither obviously does what I need.
Is this an intended change to SQLite Tcl bindings, a bug, or just
something else I'm missing?
Thanks for any insight.
Jeff Godfrey
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
