My point of view. Right now I have to use BDE (Borland Databse Engine). It is slow, small SQL embadden engine, which works on Paradox / DBase files (I know - many others, but for description that two is all you need to understand it). I don't like ADO, problems with installig, many standards - many problems. BDE is rarely used, so less possibilities for conflict. Also the core is much smaller. For me the only point is that it can work on shared directories. Case in details. There is small company with up to 5 PCs with Winodws. Win9X, mixed with WinNT/Win2K. You see if there is bigger company they have clients the same - and serwer, so I think it is not case for SQLite. For most cases there are only two PCs... but the data have to be shared! Here is first comment to the paper. All the data have to be accessed all the time (except the moments when trasaction is commited, and the data is changing). In this case network should be saved. I mean - it is slow, and form time to time... ;) Under BDE opened trasaction can keep files uncosistent, so when something goes wrong... In most cases nothing is lost, inices are wrong. It works like that: user starts transaction, makes some changes, changes are commited, transaction goes and... at the moment data is sent but structure of indices is wrong... It is common example, but only one. ;)
Proposal. I think it would be nice to have file or other place with chages. DB file would not be changed until commiting of transaction. Note that you do not need local file - only special cache and redo log. Special, becouse it can not be reused when trasation is uncommited. Redo log for storing information about changes. When the engine commits transaction redo log is beeing send to the serwer - like Write Ahad Log under PG. Then tables are locked - eg. with side file, like under ADO/Access. Information from redo log is pocessed. If light-off happends all the data is in one place and first accesser can repair corrupted file. Also any problem with connection can be reported when sending redo log timeouts. The problem is when transaction consumes to much cache... Other option is like under PostgreSQL - change makes copy, so all others can read orginal data - instead changed (and uncommited). But PG has (auto)vacuum system. Under SQLite I have no idea who should take care about that. Next aspect is communication betwean transactions. PG has is serials, so every transaction has unique values... It can be done by locking file with the values. All that changes will slow down SQLie ;( It would be nice to allow turnig off.
I hope it helps.
-- Regards, Michal Zaborowski (TeXXaS) http://sqlite4delphi.sourceforge.net/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
