On 2016/06/13 3:41 PM, Luc DAVID wrote:
Thanks Ryan and Oliver for your answers
You are too fast for me, I didn't have the time to answer the first
posts...
@Ryan
> There is no safe way to do what you need. Networked file systems do not
> play nice with file-locking. SQLite is suitable for localized storage,
> not Networked-multi-user-access systems. You need a client-server
> architecture for that.
I know sqlite cannot be "safely" used on a shared network file system
but I'm not sure this is the case here : I believe (May be I'm
completely wrong here, and this is the main point) Windows server with
TSE doesn't use NFS between rdp clients, as the exe + db + dll are on
the same storage but use a different memory space between TSE connexion.
I'm not a windows server TSE expert so I can't tell but I'm hoping
someone can
@Oliver
I won't be able to statically link sqlite in the exe (I wish I could...).
I use "immediate" transaction when writing and try as much as possible
long write operation.
No need to link it, that is just (as Oliver mentioned) a best-way case,
but not the only workable case. It should work fine as you described.
Also, if you are sure the DB file is on local storage, i.e. on one of
the drives directly accessed by the server computer (such as its C:\
drive or D:\ drive etc, not something like a mounted drive ro a drive
starting with \\SOMESERVER\xxx\... then you should be perfectly fine and
steer clear of any locking issues.
Once the above is ensured, you could simply add an adequate time-out to
make SQLite do the work of waiting for in-progress transactions for you
(you can have large timeouts, of say a minute or more even), starting
transactions wisely and ending them as soon as possible will help. With
WAL mode you get the luxury of being able to read data from the DB while
someone else is writing (but nobody can write simultaneously still). It
should all work well and without any problems - but please log errors
and ask if you see anything funny.
The worst case is when you get a "Database is locked" message which
mean you have to kill all the application processes in order to unlock
the db (unless another means exists ?)
Yes, but the timeout setting will still sort this out for you, unless
you have commits/transactions that take stupidly long to complete.
See:
https://www.sqlite.org/c3ref/busy_timeout.html
https://www.sqlite.org/pragma.html#pragma_busy_timeout
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
