Error: Unable to open the database file

[Peter Haworth]

I do remember a post from you about not being able to send multiple
statements to SQL in one Livecode call, and also I'm pretty sure it was
confirmed. so that's probably what you're thinking of.


On Wed, Apr 6, 2016 at 10:17 AM Dr. Hawkins <dochawk at gmail.com> wrote:

> On Wed, Apr 6, 2016 at 9:42 AM, Peter Haworth <pete at lcsql.com> wrote:
>
> >
> > mySQL does have transactions, as do all SQL implementations.  They're
> part
> > of the SQL spec.  postGresql may well have advantages over mySQL but that
> > isn't one of them.
> >
>
> Now I'm trying to remember: is it that livecdoe that can't successfully
>  pass a compound command to mySQL?
>
> So that BEGIN, each command, and END each take a separate live code
> command?  That turns it into a brutal multiplier for a remote database, and
> one to watch on a local.
>
> I remember that mySQL was a flat-out deadend for me; I started with it when
> I realized that SQLite wasn't going to do it for the remote.
>
> Tje more I think about it, the more I think it's live code's
> implementation; maybe that is getting fixed in 8.
>
>
> > It's quite feasible to implement multi-user sqlite applications.  There
> are
> > several examples on the SQLite web site and in fact their website is
> driven
> > by an sqlite database.  Of course it depends on the needs of the
> > application, as it always does.
> >
>
> "SQLite does not compete with client/server databases. SQLite competes with
> fopen()."
>     from https://www.sqlite.org/whentouse.html
>
>
> I'm going to be going the middleware route myself, but i'm not switching
> until everything else is done.
>
> I'm dealing with the presumption of multiple users accessing the same
> "case" at once--at least the lawyer's desk, secretary's computer, and the
> lawyer from court.
>
> At the moment, I periodically (about 30 seconds) send a transaction to the
> server with all of the updates that also scoops back any updates from the
> remote.   I don't need to worry about inconsistencies from users, and can
> simply use the latest value entered, without regard to whether there was an
> earlier unknown change (If Beth enters $20,000 for income, and Sarah enters
> $30,000, the office or data has bigger problems than I can solve).
>
> I very briefly synched each transaction as it occurred using remote mySQL;
> this was  brutally slow as each changed variable causes a cascade of it's
> dependencies; it was a noticeable fraction of a second to tab to the next
> field . . . (kind of like tabs in the IDE when you have multiple large
> scripts . . .)
>
> While I could stay with the current method for the distributed product once
> the ssl postgres is implemented, there are enough advantages to me for a
> persistent server that I'll still switch.   In particular, it lets me go
> asynchronous:  the client program writes and forgets, eliminating most of
> the transactions it initiates, and receives messages from the server on the
> socket when something changes at that end (which would always follow
> shortly after its own transmission).  The server on a VPS or even dedicated
> server simply watches the open sockets on a round robin basis, and writes
> back any changes (or, potentially other messages) to the client.
>
>
>
>
> --
> Dr. Richard E. Hawkins, Esq.
> (702) 508-8462
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>