You stated off by making some assumptions which would normally be correct, but
are not valid for SQLite. Your last two paragraphs suggest you realized what
was really happening. There is no persistent SQLite Server process, accepting
requests from many users. SQLite has no multi-user model and is not primarily
intended for use as a server/client database. All changes are performed by
changing data in the database file or in temporary 'journal' files on disk.
The only thing you could say is shared between users is whether the file on
disk is locked (indicating that it's currently being updated by a user) or not.
Think of SQLite as the simple database system your TV uses to list channel
names, or your mobile phone uses to keep its phone book (both of which are, in
fact, things SQLite really is used for with literally millions of
installations). The fact that SQLite works at all with huge datasets being
accessed by many users at once is just a result of good programming.
As your questions indicate, if you're starting off a programming project
intending to use big datasets accessed concurrently by many users across a
network, SQLite is probably not the right database engine to use. More about
this can be found at
<http://www.sqlite.org/whentouse.html>
Simon.
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Hi Simon
Thanks for your very helpful post.
Actually for everything I want to do DB-wise, sqlite is perfect . I
actually wanted to understand this to use in a totally different project
using the Ada language.
Have a great day-Patrick
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
