Re: [sqlite] Are SQLite offer dates with timezone support?

2004-10-16 Thread D. Richard Hipp
Tito Ciuro wrote:
Hello,
The only reference I see about timezone support in SQLite is in this 
example:

Compute the date and time given a unix timestamp 1092941466, and 
compensate for your local timezone.
SELECT datetime(1092941466, 'unixepoch', 'localtime');

I found this here: 
http://www.sqlite.org/cvstrac/wiki?p=DateAndTimeFunctions

Where can I find more info?
Timezones are enormously complicated, mostly because daylight saving
time rules.  Every locale does it a little bit differently.  And the
rules change from year to year.
So, no, I am not going to fight that battle.  Doing timezones correctly
could easily double the size of the library.  If you need timezones,
link in a separate library that focuses on timezones.  SQLite is going
to stay focused on storing and retrieving data.
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565


[sqlite] Are SQLite offer dates with timezone support?

2004-10-16 Thread Tito Ciuro
Hello,
The only reference I see about timezone support in SQLite is in this 
example:

Compute the date and time given a unix timestamp 1092941466, and 
compensate for your local timezone.
SELECT datetime(1092941466, 'unixepoch', 'localtime');

I found this here: 
http://www.sqlite.org/cvstrac/wiki?p=DateAndTimeFunctions

Where can I find more info?
Thanks,
-- Tito


Re: [sqlite] BLOBs and sqlite_exec

2004-10-16 Thread Will Leshner
On Oct 16, 2004, at 2:04 AM, D. Richard Hipp wrote:
Will Leshner wrote:
Sorry if this is terribly obvious, but I'm assuming that, in SQLite3, 
we can't use the sqlite_exec convenience API to store BLOBs, right?
Correct.  The only way to insert a BLOB is using sqlite3_prepare()
followed by sqlite3_bind_blob().
Thanks. That makes a lot of sense, actually.


Re: [sqlite] BLOBs and sqlite_exec

2004-10-16 Thread D. Richard Hipp
Daniel K wrote:
I think there might be something, but I can't remember
exactly. It might be:
INSERT INTO tbl VALUES ( X'ABCD' );
where ABCD is the hex representation of the blob data.
If you do a ".dump" command from the shell on a
database that contains blobs and look at the output it
might prove illuminating.
Right, Dan.  I forgot about that.  You can insert a BLOB
using sqlite3_exec() if you first encode the BLOB as a
hexadecimal blob constant.
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565


Re: [sqlite] BLOBs and sqlite_exec

2004-10-16 Thread Daniel K

--- "D. Richard Hipp" <[EMAIL PROTECTED]> wrote:

> Will Leshner wrote:
> > Sorry if this is terribly obvious, but I'm
> assuming that, in SQLite3, we 
> > can't use the sqlite_exec convenience API to store
> BLOBs, right? 
> > 

I think there might be something, but I can't remember
exactly. It might be:

INSERT INTO tbl VALUES ( X'ABCD' );

where ABCD is the hex representation of the blob data.

If you do a ".dump" command from the shell on a
database that contains blobs and look at the output it
might prove illuminating.

Dan.







___
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com


Re: [sqlite] BLOBs and sqlite_exec

2004-10-16 Thread D. Richard Hipp
Will Leshner wrote:
Sorry if this is terribly obvious, but I'm assuming that, in SQLite3, we 
can't use the sqlite_exec convenience API to store BLOBs, right? 

Correct.  The only way to insert a BLOB is using sqlite3_prepare()
followed by sqlite3_bind_blob().

--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565


Re: [sqlite] multiple indexes.

2004-10-16 Thread D. Richard Hipp
Guillaume Fougnies wrote:
Hello,
I'd like to know if the management of multiple indexes
on select statement is in the TODO list of SQLite?
No.
On joined request, this lack is a real performance killer.
Example:
select t1.id,t2.name
from t1,t2
where t1.id IN(a00,b00, ,z99) and t1.t2id = t2.id;
For now, SQLite use by default the wrong index and make
a full join ignoring the 'IN' restriction. I need
to force the index selection like this to gain a little
speed:
select t1.id,t2.name
from t1,t2
where t1.id IN(a00,b00, ,z99) and +t1.t2id = t2.id;
I think you are in error.  In the situation about, SQLite
will never chose to use an index on t1.t2id.  It will always
use the t1.id index (if there is one) for locating rows
in table t1 and it will use the index on t2.id for locating
rows in t2.  This is true regardless of whether or not you
attempt to disable the indices using the "+" sign.
If you need help optimizing a query, post all relevant parts
of the schema and the query you are working on and we will
take a look.

--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565


Re: [sqlite] LIKE, BETWEEN

2004-10-16 Thread D. Richard Hipp
Mike Ponomarenko wrote:
In sqlite3 queries using LIKE and BETWEEN do not use existing indices.  So for
a schema like
CREATE TABLE t (a integer, b char(40));
CREATE INDEX t_idx_0 ON t(a);
CREATE INDEX t_idx_1 ON t(b);
queries like
"SELECT * FROM t WHERE a BETWEEN 1 AND 20"or
"SELECT * FROM t WHERE b LIKE 'abc%'"
end up doing a table scan.
Just curious if there are any changes in the works to make queries such as above
use available indices?
No
For BETWEEN:  Integer 2, MoveGE, Next until > 20, etc.
For LIKE: if one parameter is a string with a constant prefix, String8 'abc',
MoveGE, Next until Function(LIKE) fails, etc.
I realize that queries can be rewritten to make them more efficient (SELECT *
FROM t WHERE a >= 1 AND a <= 20), etc., but it's not always feasible.  I'd
appreciate any thoughts on the matter.  Thanks!
Every effort is made to keep SQLite simple, small, and fast.  Adding
lots of code to do expression optimizations that could just as easily
have been done by the user is contrary to those goals.
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565


Re: [sqlite] SQLITE_BUSY returned without busy handler called

2004-10-16 Thread D. Richard Hipp
Kevin Schmeichel wrote:
  By examining the code, it can be seen that there are
many places where SQLITE_BUSY is returned (from an API
function) without the busy handler being called.
  Anyone know if there is any reason for this?  I
would have thought that the busy handler would be
called *every* time that the db is busy.
There are circumstances where waiting and retrying a lock
will not help.  In those cases, there is no point in
calling the busy handler.  The busy handler is also not
called when failing to obtain a RESERVED lock unless
the library is recompiled with -DSQLITE_BUSY_RESERVED_LOCK=1.
Not waiting on a reserved lock helps to resolve locking
conflicts faster.
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565


Re: [sqlite] Support for ODBC?

2004-10-16 Thread Yves Chaufour
Le vendredi 15 Octobre 2004 09:23, Eric Bohlman a écrit :
> R S wrote:
> >   Can an application access data from SQLite via ODBC? Didn't see
> > documentation on the same.
> 
> If you have an ODBC driver for SQLite, yes.  The "SQLite Wrappers" page 
> of the wiki mentions "ODBC driver for SQLite. 
> http://www.ch-werner.de/sqliteodbc/";.  I don't know anything about it, 
> but check out the URL.
> 
The SQLite ODBC driver has been written by Christian Werner and make it 
possible to access a SQLite database file from applications which are ODBC 
compatible.
I use it with OpenOffice.org in linux and windows.
You can find here a how-to about that 
(http://documentation.openoffice.org/HOW_TO/data_source/SQLite.sxw)

I hope this will help you.

Yves


Re: [sqlite] GUI ?

2004-10-16 Thread Demitri Muna
Take a look at the excellent QuickLite Cocoa wrapper.
http://www.webbotech.com/
It has a few sample applications, including one called "SQLIteManagerX" 
which may be sufficient for your needs.

Demitri
---
On Oct 15, 2004, at 8:53 PM, Richard wrote:
wondering if there are any Mac OS X GUI front-end apps,
that will work with SQlite ?
Thanks -
Richard