Error: Unable to open the database file

[Dr. Hawkins]

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