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*", "*OID*", or "*_ROWID_*"." If I use a
column name (as defined by my Create Table) in a select statement,
Rexx variables are set (using RexxSQL here) in the form
x.columnname.n -- except if the column name used is OID, in which
case the Rexx variable set is x.ROWID.n instead of the expected
x.OID.n No mention is made in the documentation of this "quirk",
which behavior is different from that of SQLite version 2.
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 results, a compatibility issue. Version 3 documentation
states that "SQLite may attempt to convert values between the
numeric storage classes (INTEGER and REAL) and TEXT before
performing a comparison." Apparently this is not done in the case
of "Select Where column = '1'" and a particular row has been set
with a value of unquoted 1. (Columns were defined with no type.)
The v3 document (in discussing conversions) uses the expression
"affinity is applied" without defining what that means. Does it
mean "conversion to"?
-R.
D. Richard Hipp wrote:
> 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 variables
>>> x.ROWID.n
>>>
>
> The "name" of a result column is undefined unless you use the "AS"
> clause. We try to be reasonably consistent, but there are no
> promises. There are especially no promises when moving form 2.8 to 3.6
>
>
>
>>> 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 Field='3' and different rows where
> Field=3 and SQLite will distinguish between them.
>
> D. Richard Hipp
> d...@hwaci.com
>
>
>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
>
>
--
Regards, Rod Dav4is / P.O. Box 118 / Hyde Park, NY 12538 / USA
Genealogy, et Cetera: http://freepages.rootsweb.ancestry.com/~dav4is/
538 ancestral & collateral families, mostly 17°-19° century
New England & European roots. Total population: 136,000+
Annex: http://www.gencircles.com/users/dav4is/
email: dav...@yahoo.com
A Democrat, a Republican and a giraffe walk into a bar. The
bartender looks up from his want ads and says, "What is this, a joke?"
-unknown
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
