The thing is, SQLite's synchronization mechanism is simpler than most full-featured SQL databases. In all cases, the point is that if you are attempting to do simultaneous writes from two connections, each connection must be prepared to receive an error, rollback the transaction, and try again.
Personally, I don't see anything terribly complicated about that. Concerning yourself with the intricate details in order to get the best performance is complicated, sure, but the basic principle isn't. You have to do error checking anyway, the only difference is that it may affect your entire transaction rather than just one statement. That's true for working with SQL databases in general. For those applications don't want parallel access at all, SQLite provides BEGIN EXCLUSIVE. Adding your own mechanisms on top just means another thing for you to test independently, which seems like adding complexity. I do recognize that none of the above necessarily applies to specific environments, where you need to do your own thing anyway. I'm just commenting that in general, SQLite is already simple to use. ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------