I think the answer to your question depends on the level of
concurrency you expect. You'd definitely need to implement the SQLite
locking mechanisms to support concurrent users (BEGIN/END/ROLLBACK
TRANSACTION).
Check out sqlite.org, the home of sqlite, there's some words on there
about multi-use concurrency. particularly at
http://www.sqlite.org/whentouse.html
and
http://www.sqlite.org/faq.html
They seem to indicate that many users reading and a few users writing
will probably be OK.
I'd also recommend that you ask this question on the sqlite users
forum. You can join it at http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Pete
On Nov 23, 2010, at 6:15 AM, Andre Garzia wrote:
Fredrik,
Instead of risking problems by having concurrent queries to a single
SQLite
database, why don't you build a middleware?
From your email, I understood that the problem is that you can't
install a
server such as MySQL because the IT dept will be shouting. So why
don't you
use LiveCode to build a little self contained server which talks to
SQLite,
then all the clients would talk to this same server, this way,
there's no
concurrent access since everything passes thru the server.
If you're on LAN then it would be überquick to get the data around
and you
would not have to face multi user access to a single file resource
(this is
always troublesome).
Andre
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
