Inter-Application Communication on Windows
dave at looktowindward.com
Fri Feb 15 07:57:28 EST 2008
I think it's easier to use TCP to communicate rather than try to hack
something to together that wasn't really designed for the job. The
problem is that I'd have to lock the database for very long periods
(10 to 15 minutes or more), and so I'd lose whatever gain was to be
had by splitting the apps. In fact I may as well just implement it as
a single app which is what I have now!
All the Best
On 15 Feb 2008, at 12:21, viktoras didziulis wrote:
> I wonder whether it is because the instances change the schema of
> the database or because they do it simultaneously ? Maybe if you
> implement a simple locking mechanism it would work ?.. The simplest
> way, which I never tried in Rev, but many times in Perl when
> programming multiuser shared flat file based solutions is using a
> semaphore file.
> When an instance of app needs to write data to a shared flat file it:
> 1) checks if semaphore file (an empty file with known name, e.g
> anything like "busy.sem", "busy") is present
> 2) if it is present it waits and returns to 1) in a few
> milliseconds otherwise it
> 3) creates the semaphore file and writes data into the shared file
> 4) then deletes the semaphore
> All the best!
> Dave wrote:
>> The problem with my Application is that whole Tables can be
>> renamed or deleted. Just tried running two apps at the same time
>> accessing one database and it instantly crashed and the database
>> is in pieces!
>> All the Best
>> On 14 Feb 2008, at 13:30, viktoras didziulis wrote:
>>> Hi Dave,
>>> in one of my applications I use shell to communicate with sqlite
>>> for data .import and revolution's sqlite to query and modify the
>>> same database. It was never corrupted... Maybe just
>>> because .importing and modification are sequential and do not
>>> attempt to modify the same database in the same time.
>>> I am frequently using an instance of commandline sqlite and an
>>> instance of sqlitespy for some database tests - it possibly can
>>> corrupt the database, but so far this has never happened.
>>> Accessing the same sqlite database should not make any big
>>> troubles unless both sqlite instances modify the database
>>> simultaneously. In this case you may try implementing some sort
>>> of locking mechanism. But then the solution with file would be
>>> I did a test with a very very simple sqlite app - it did not
>>> corrupt the database even if many instances of it were running...
>>> So you can read, insert or delete a record in a table with one
>>> instance and read it with another and vice versa... But I guess
>>> there are scenarios when the database can get corrupt.
>>> The zipped folder with both the compiled app (for Windows) and
>>> the source can be downloaded from:
>>> Best wishes
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the Use-livecode