Çağlar Orhan
Hi Larry, thank you for your explanatory answer. I have an idea now, but
with my poor English am afraid i did understand wrong or incomplete :(
I am going to try my network layout.
We have an IIS as a server and clients have MS Win7 on their PCs.
But usually we used IIS machine as a clasical static file storage. So i do.
There is one mydb.sqlite file as DB on somewhere at IIS.
IIS not to pay any atention on the file and not to run any application on
itself.
But every client has MS *.hta files and connecting to sqlite over ODBC
driver with vbscript. That means 5-10 or few larger client counts make
connections to that unique sqlite file on the IIS server.
Every client (5-100) all over the network has their own application which
takes aim at mydb.sqlite file as DB target source.
Basically proceses are just read and write to table.
And you wrote
"What Jay and others warn about is that SQLite is not designed for
concurrent DB operations. Also, have its file store be accessed over a
network from SQLite code running remotely is a formula for database
corruption. But it looks like you are not doing that."
Is my situation comply with warning :(
From your first post, I understood that the IIS server would be doing
all the SQLite operations, (likely from multiple threads, although that
could only be surmised).
Now, it appears that you have clients on different machines accessing a
SQLite file over the network via their own SQLite code. This is
precisely what the warning advises against. The problem is this: Even
though the SQLite design anticipates different processes operating on
the same database file, it guards against concurrent access issues by
using file locking and another file located "beside" the database file
to control access and provide journalling. If file access over a
network had the same semantics and predictability as machine-local file
access, then there would no reason your usage would not work.
Unfortunately, file access over a network has known weaknesses with
respect to file locking. This means that such access involving running
SQLite code and a remote database file is unreliable when multiple
clients may perform nearly concurrent operations. Just as network file
locking sort of works, your application(s) may sort of work, at least
enough for some simple tests to seem successful. You would do well to
avoid deploying such a solution.
You might be interested in this "Code Project" article, and perhaps its
code:
http://www.codeproject.com/Articles/22416/A-SQLite-Server-Client-Implementation
Thank you,
You're welcome,
--
Larry Brasfield
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
