1. *re OID vs ROWID:* I don't understand your statement that the
name of a result column is undefined. The documentation clearly
states A column name can be any of the names defined in the
CREATE TABLE statement or one of the following special
identifiers: *ROWID*,
2. *re integer vs string:* Version 3 differs from version 2 here.
Version 2 was declared to be typeless and Select Where column =
1 behaved identically with Select Where column = '1'. Version
3 behavior is different in that the two previous examples produce
different
2. *Quotes in SELECT*: Specification of Field='3' failed to find
hits; Field=3 (i.e. without quotes) was required.
This is a feature, not a bug. SQLite 3.x distinguishes between
integers and strings and does not consider them equal to one another.
You might have some rows where
Pavel Ivanov wrote:
2. *Quotes in SELECT*: Specification of Field='3' failed to find
hits; Field=3 (i.e. without quotes) was required.
This is a feature, not a bug. SQLite 3.x distinguishes between
integers and strings and does not consider them equal to one another.
You
Perhaps the fact that my column definitions declared no
typing has an effect here?
Yes, that means that your columns have no affinity, all data stored in
it as you give and no conversions done during insertions and
comparisons:
sqlite create table t (n, t);
sqlite insert into t values (1,
Pavel Ivanov wrote:
2. *re integer vs string:* Version 3 differs from version 2 here.
Version 2 was declared to be typeless and Select Where column =
1 behaved identically with Select Where column = '1'. Version
3 behavior is different in that the two previous examples
Pavel Ivanov wrote:
Perhaps the fact that my column definitions declared no
typing has an effect here?
Yes, that means that your columns have no affinity, all data stored in
it as you give and no conversions done during insertions and
comparisons:
sqlite create table t (n, t);
Yes, I know how it works. But that seems to contradict the
documentation. The first field of the record inserted should have a type
of numeric, as types are associated with the data not with the column
declaration. So the phrase Where n = '1' should fall into the first
bullet case
Rod, type
Umm,
At 05:16 03/09/2009, you wrote:
´¯¯¯
Thanks for reminding me: A thing's value is generally proportional to
its cost. And the attitude of its support team figures in there, too.
-R.
Whether _you_ consider them problems or not, they were certainly
problems for me, migrating a working
*re applied affinity:* If that is what is meant, then the document
should say it, instead of leaving it to the reader's imagination.
Since column typing was superfluous in version2, it seems that the
version3 adoption of typing, as defined, would perhaps be an upgrade
compatibility
Whoa! All I did was report two problems that I encountered when
upgrading from version2 to version3! I was told that my problems were
not problems at all; In fact one of them was a feature! That sounds
kinda arrogant to me.
As far as freezing the language, I made no such statement or
On Sep 3, 2009, at 10:43 AM, Rod Dav4is wrote:
*re applied affinity:* If that is what is meant, then the document
should say it, instead of leaving it to the reader's imagination.
Since column typing was superfluous in version2, it seems that the
version3 adoption of typing, as
Hipp d...@hwaci.com
To: General Discussion of SQLite Database sqlite-users@sqlite.org
Sent: Thursday, September 03, 2009 8:05 AM
Subject: Re: [sqlite] Problems encountered on upgrade from SQLite2
to -3
On Sep 3, 2009, at 10:43 AM, Rod Dav4is wrote:
*re applied affinity:* If that is what
To: General Discussion of SQLite Database sqlite-users@sqlite.org
Sent: Thursday, September 03, 2009 8:05 AM
Subject: Re: [sqlite] Problems encountered on upgrade from SQLite2
to -3
On Sep 3, 2009, at 10:43 AM, Rod Dav4is wrote:
*re applied affinity:* If that is what is meant
Whether _you_ consider them problems or not, they were certainly
problems for me, migrating a working application to version 3 and having
it fall over in subtle ways because of these undocumented two vs three
differences. They cost me several hours of unnecessary analysis time.
D. Richard Hipp
On Wed, Sep 2, 2009 at 3:54 PM, Rod Dav4isdav...@yahoo.com wrote:
Whether _you_ consider them problems or not, they were certainly
problems for me, migrating a working application to version 3 and having
it fall over in subtle ways because of these undocumented two vs three
differences. They
Thanks for reminding me: A thing's value is generally proportional to
its cost. And the attitude of its support team figures in there, too.
-R.
P Kishor wrote:
On Wed, Sep 2, 2009 at 3:54 PM, Rod Dav4isdav...@yahoo.com wrote:
Whether _you_ consider them problems or not, they were certainly
Rod Dav4is wrote:
Thanks for reminding me: A thing's value is generally proportional to
its cost. And the attitude of its support team figures in there, too.
-R.
There is only one person with attitude I see here, and it is not Dr.
Hipp and it is not P. Kishor.
I have never seen a program,
Aren't these problems considered worth fixing ?
Rod Dav4is wrote:
1. *OID vs ROWID*: Specification of the OID field name (in SELECT)
did not set Rexx variables X.OID.n, but instead set variables
x.ROWID.n
2. *Quotes in SELECT*: Specification of Field='3' failed to find
On Sep 1, 2009, at 4:38 PM, Rod Dav4is wrote:
Aren't these problems considered worth fixing ?
I do not consider them to be problems.
Rod Dav4is wrote:
1. *OID vs ROWID*: Specification of the OID field name (in
SELECT)
did not set Rexx variables X.OID.n, but instead set
1. *OID vs ROWID*: Specification of the OID field name (in SELECT)
did not set Rexx variables X.OID.n, but instead set variables
x.ROWID.n
2. *Quotes in SELECT*: Specification of Field='3' failed to find
hits; Field=3 (i.e. without quotes) was required.
--
Regards, Rod
21 matches
Mail list logo
