On Feb 9, 2012, at 4:17 PM, Marco Bambini wrote:
> sqlite 3.7.8 on MacOS X
>
> This query works fine:
> SELECT rowid, * FROM 'customer' WHERE rowid < 100;
>
> While this query does not return anything:
> SELECT rowid, * FROM 'customer' WHERE 'rowid' < 100;
>
> Do you have an explanation?
per
sqlite 3.7.8 on MacOS X
This query works fine:
SELECT rowid, * FROM 'customer' WHERE rowid < 100;
While this query does not return anything:
SELECT rowid, * FROM 'customer' WHERE 'rowid' < 100;
Do you have an explanation?
--
Marco Bambini
http://www.sqlabs.com
http://twitter.com/sqlabs
_
Yes, you are right (as always).
Time with SQLITE_THREADSAFE=0 is about 4.33 seconds now.
Thanks a lot.
--
Marco Bambini
http://www.sqlabs.com
http://www.creolabs.com/payshield/
On Aug 28, 2009, at 5:23 PM, D. Richard Hipp wrote:
>
> On Aug 28, 2009, at 11:17 AM, Mike Eggleston wrote:
>
>> O
On Aug 28, 2009, at 11:17 AM, Mike Eggleston wrote:
> On Fri, 28 Aug 2009, Marco Bambini might have said:
>>
>> Version 3.4.2 takes about 5.06 seconds (average value) while version
>> 3.6.17 takes about 7.28 seconds (average value).
>> Could be a slowdown in the library for the complexity added o
Library is statically linked into the final app and the db is newly
created...
--
Marco Bambini
http://www.sqlabs.com
http://www.creolabs.com/payshield/
On Aug 28, 2009, at 5:17 PM, Mike Eggleston wrote:
> On Fri, 28 Aug 2009, Marco Bambini might have said:
>
>> Hello,
>>
>> today I made
On Fri, 28 Aug 2009, Marco Bambini might have said:
> Hello,
>
> today I made some test on a project I wrote some years ago.
> I upgraded sqlite library from version 3.4.2 to version 3.6.17.
> What I am really unable to understand is the time difference required
> to perform the same query usin
Hello,
today I made some test on a project I wrote some years ago.
I upgraded sqlite library from version 3.4.2 to version 3.6.17.
What I am really unable to understand is the time difference required
to perform the same query using the exact same algorithm by the two
libraries.
SELECT * FROM
Hello Dr. Hipp,
On 1 may 2004, at 8:38, D. Richard Hipp wrote:
When you do a "SELECT *", the results contain only columns
that are explicitly declared in the CREATE TABLE statement.
If you have declared an INTEGER PRIMARY KEY column, then
the rowid will appear under that column name. If there is
Every row of every table has a ROWID. The ROWID can be
called "ROWID", "_ROWID_", and/or "OID". All three names
refer to the same value and can be used interchangably.
But if you declare a column with any of those names, the
name refers to your declared column, not the actual
ROWID. This is simi
Tito Ciuro <[EMAIL PROTECTED]> writes:
> Hello,
>
> A few days ago I posted a question and I haven't seen any comments so
> far. I'm really curious about ROWID's volatility. How can I make sure that
> ROWIDs do not get re-initialized? I'm posting the message once again hoping
> that someone will e
Tito Ciuro wrote:
Hello,
A few days ago I posted a question and I haven't seen any comments so
far. I'm really curious about ROWID's volatility. How can I make sure
that ROWIDs do not get re-initialized? I'm posting the message once
again hoping that someone will explain how I should properly
Hello,
A few days ago I posted a question and I haven't seen any comments so
far. I'm really curious about ROWID's volatility. How can I make sure
that ROWIDs do not get re-initialized? I'm posting the message once
again hoping that someone will explain how I should properly use
ROWIDs.
Thank
Hello,
Would this explanation about ROWID make sense?:
Referencing ROWID: If you make references to ROWID but then export
your database (using, for example, the ".dump" command of the sqlite
shell) and reimport it, all of your ROWIDs will change and your
references won't
be right any more. If
13 matches
Mail list logo
