Error: Unable to open the database file

Ray ray at linkit.com
Wed Apr 6 13:38:08 EDT 2016


I haven't gotten that far into the database syntax and Livecode's 
handling of it yet so I couldn't say, yet.  But I'm sure I'll figure out 
soon what, if any, Livecode's limitations are.

So Richard, what did you end up going with when neither sqLite nor mySQL 
worked out for you?


On 4/6/2016 1:16 PM, Dr. Hawkins 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.
>
>
>
>





More information about the use-livecode mailing list