I have been using SQLite for over a year now and it is an excellent SQL
Library. Some more features from SQL92 would surely be welcome while keeping
SQLite fast and small. Suggestions for ver 3.0 include:
- Full referential integrity by implement check and foreign key
The proposal for version 3.0 looks very promising and I hope all the major
will be implemented. Most of the enhancements seem to add flexibility and
to the "C" based api. This is great as at the "C" api call level you can do
anything you want.
But I do not see any changes
I would like to add some commands to SQLite to make my SQL(ite) programming
The commands are:
IF - e.g IF ((select count(*) from foo) = 100)
Yes...It would be great if SQLite had control-flow statements and variables
Transact-SQL(MS/Sybase) as it would allow one to put all the data
one script and run it like a stored procedure...
I do like the fine control that SQLite gives my application but I also think
Great...can you tell me if there will be any increased technical specs???
Ver 3.0 will have a 64-bit ROWID, what about:
- page size
- max table rows
- max database size
- max blob size
- any other tech limitations info...
I totally agree...
Seems like when users say SQLite is slower than "xyz...", they are using
a high level driver based interface instead of using a "c" based driver
really test what SQLite is doing.
I have written tests at the "c" level for both MySQL and SQLite
and SQLite is generally
Puneet Kishor wrote:
> my guess is because it can be done other ways (see the docs on this
> specifically), and the idea is to keep SQLite as simple as possible. The
> more "conveniences" that are added to it, the more complicated it will
> Usually, once the database is set, there
Yep. basically our "type less" string fields should have user definable
operator overload functions. Sounds like a big change that I doubt DRH would
implement anytime soon but it would definitely solve some of these
integer/numeric/string/datetime/etc.. conversion/comparisons. We would also
I would like to use SQLite on a web server or .net remoting and
multi-user/threads may become an issue
as locking is based at the finest granularity of file locking instead of
table/page/row locking. Will this issue be resolved from 3.x onwards so that
concurrency can be increased when multiple
The main reason for file locking is to support win95/98/ME???...
I do have a server process running and have embedded sqlite to be used by
that may be started. All writes currently go to one writer thread and this
seems to work fine.
The application we have developed
I really like this answer!!!
The Goldilocks approach to increased concurrency...
Hopefully DRH will read your answer and conclude this would be a good
as the current take it or leave it answers are no help.
Abandoning SQLite COMPLETELY for higher concurrency does not make sense but
> What's the objection to reading your SQL source out of the database and
> preparing it at program startup?
I have no objection to reading the sql on startup as that is what we are
currently doing. I just want all data access code inside of the database
instead of my source code. Does anyone
Mail list logo