- Forwarded by Ben Carlyle/AU/IRSA/Rail on 31/03/2004 02:38 PM -
Ben Carlyle
31/03/2004 02:34 PM
To: "D. Richard Hipp" <[EMAIL PROTECTED]>@CORP
cc:
Subject:Re: [sqlite] Concurrency Proposal
Peoples,
"D. Richard Hipp" <[EMAIL PROTECTED]>
sqlite> select datetime(1080701286,'unixepoch');
2004-03-31 02:48:06
sqlite> select datetime(1080701286,'localtime');
2954147-07-10 07:00:00
sqlite> select datetime(1080701286,'unixepoch','localtime');
2004-03-30 21:48:06
sqlite> select julianday('now');
2453095.66955468
sqlite> select
> way, the mapping table would be the responsibility
> of the pager layer which (up until now) has known
> nothing about the btree layer. But with this approach,
> the pager layer would need to call the btree layer
> recursively. Thinking about that is starting to
> make my head spin.
> Does
Kenneth Lo wrote:
I think the time() function is not reporting the correct time. The date part
is OK. I also note that CVSTrac uses C codes to handle datetime i.e. not relying
on sqlite. Is there a bug?
Some investigation ...
bash-2.05b$ date
Wed Mar 31 11:12:03 HKT 2004
bash-2.05b$ sqlite
SQLite
I think the gist of Ben's proposal is as follows
(please correct me if I am wrong):
Writes do not modify the main database file until
they are ready to commit - meaning that reader can
continue to read from the file during lengthy
transactions. The journal contains modified pages,
I think the time() function is not reporting the correct time. The date part is OK.
I also note that CVSTrac uses C codes to handle datetime i.e. not relying on sqlite.
Is there a bug?
Some investigation ...
bash-2.05b$ date
Wed Mar 31 11:12:03 HKT 2004
bash-2.05b$ sqlite
SQLite version
G'day,
I've been mulling over this for a little while, but only got around to
writing anything down last night. I may have made some errors, perhaps
serious ones. Either way, I thought I'd just put it out there. This email
contains an algorithm for permitting concurrent reader and writer
Just starting out in ruby.
I have:
ruby 1.8.1
ruby dbi 0.0.21
mdk linux 10.0
did the following without problems:
ruby setup.rb config --with=dbi,dbd_sqlite
ruby setup.rb setup
ruby setup.rb install
running ruby test.rb (in the test directory of dbd_sqlite) I get:
I tested some more, and apparently:
In SQLite 2.7.5, the command
CREATE INDEX 'addressesZipIndex' ON 'addresses' (zip)
will create an index named addressesZipIndex (WITHOUT the single
quotes.)
The command DROP INDEX addressesZipIndex (WITHOUT single quotes) will
work as expected when
Maybe this is a TWS question (please consider I've been using TCL for
'several' hours now ! )
the html says:
<% mydb eval {select column1 from mytable where id=1} %>
and the html says:{
column1data
}
I dont want the {braces} {squirrels} {wiggles} {whatever}.
How do I omit them or strip
On Mar 30, 2004, at 9:04 AM, Jacob Engstrand wrote:
For example, I created an index using the following in 2.7.5:
CREATE INDEX 'addressesZipIndex' ON 'addresses' (zip)
Hmm. This might be a bug, actually, but if you wrapped your index name
in single quotes like that, then the quotes became
Hi All,
I've used SQLite 2.7.5 in my project for a long time, so I'm upgrading
to the latest (2.8.13). But now SQLite returns error code 1 when I try
to drop the indices I created in version 2.7.5.
For example, I created an index using the following in 2.7.5:
CREATE INDEX 'addressesZipIndex'
Thanks for your help. This way seems to be better. But it is still not
enough I think.
-- takes about 9 seconds
SELECT COUNT(ID) FROM TEST
-- takes about 5 seconds
SELECT COUNT(*) FROM TEST
--- "Williams, Ken" <[EMAIL PROTECTED]> wrote:
>
>
> > -Original Message-
> > From: Ali Sadik
13 matches
Mail list logo
