> You may be right for speed but I have never done any testing so I couldn't
> comment, but my point was regarding the ability to have concurrent writes,
> which I should have made clearer. As it happens the size of application I
> am developing this would not be a problem, but as I have learned to my
> peril over the years who knows how the same application will be used next
> year.
>
That was more or less my point..... I don't know how well access supports
concurrent writes better than SQLite. SQLite holds a block on every
update/write to the db, but with default values, if the operation takes
less than 5 seconds (the default timeout variable, that you can enlarge
using driver_args={'timeout': 30}) the problem of locking doesn't show up.
What is instead super-valid from your standpoint is that an access db
shared on a Windows network is safer than SQLite, because it seems to use
some internals at its advantage. If instead your network is samba or any
other "network-ish" mounted disk (webdav, samba, etc) concurrent writes
will not be handled so well. Also, sharing over network a file can be a lot
less "speedier" than having data exchanged with a "normal" db server. All
things considered, you may try to convince your IT department than sparing
an uncostly 128mb VM holding mysql or postgresql will make everyone's life
better.
--
