F.W.A. van Leeuwen,
I am only using SQLite. I would never consider accessing the database
file directly. Madness that way lies... :)
Bert,
I agree that SQLite should not be used multi-thread. I think there was
a lot of discussion about multi-threads using the same SQLite handle. A
big no-no :)
I am interested in mult-processor access. Which SQLite does handle.
But using a single global lock. Which I keep hitting.
I am trying to find out two things:
- If row locking was used: Is it possible for two or more processes
read/write different rows in the same table at the same time without
conflict.
- If this is the case, how can row-locking best be enforced. Whilst
maintaining integrity, speed and ease of use.
This simple addition to SQLite would make a real difference to the
abilities and target applications to which SQLite can be put to.
Ben
F.W.A. van Leeuwen wrote:
I personally don't think this is a big issue for SQLite.
A database file will typically only be accessed by the programs designed
for it (i.e., they know the format).
If another (closed source) program accesses the database file - out of
your control - it will be a problem anyway.
Typically the only ones that are out of your control are programs like
SQLiteExplorer, but they could be modified as well.
Best regards,
Frank.
