another multi-user "solution"?

[Lynch, Jonathan]

Not sure if this has already been mentioned...

But you will need a mechanism for handling a situation where a user
opens a file, then his computer crashes. At that point, he won't really
have it open, but the index will say he has it open. A possible solution
for this is for the index to not only record which files are open, but
also to record the IP address of the computer that has it open.

If the stack that accesses a data file sets itself to listen to a
particular port, then, when a different computer on the network tries to
access that data file, and sees in the index that it is open by a
particular computer, it can send a message to the IP address of that
computer verifying that it is still running.  If the original user's
computer does not respond, then the second user's computer can "take
over" ownership of that file. If the original user's computer does
respond, then the second user can return a message saying that the file
is currently open by that computer.


Another suggestion - regarding delimiters - I use ascII codes 28, 29,
30, and 31. These codes are actually set aside in the ascII set for the
purpose of delimiting files. Doing this allows you to have tab and
linefeed characters within a particular 'cell' in a data file. So far, I
have not had any problems using those characters.

-----Original Message-----
From: use-revolution-bounces at lists.runrev.com
[mailto:use-revolution-bounces at lists.runrev.com] On Behalf Of Kurt
Kaufman
Sent: Tuesday, April 26, 2005 7:59 AM
To: use-revolution at lists.runrev.com
Subject: Re: another multi-user "solution"?


> sims wrote:
>> At 10:10 PM -0700 4/25/05, Richard Gaskin wrote:
>>
>>>
>>> I'm not sure if this will work for you, but lately I've been using
>>> tab-delimited text for the sorts of things I used to use cards for.
I
>>> maintain a one-card window for display, pouring data into the fields
>>> as needed, but the data itself is maintained as just straight text.
>>> Fast, flexible, and about as small as it can be....
>>
>> Is this usually reading from text files or using custom properties?

As I mentioned, we need to have more than one user accessing parts of 
the data concurrently, so I needed the data itself to be saved outside 
of the user-operated stacks. I also wanted some sort of backup while 
the data was being worked on.  So I decided to try multiple text files, 
one for each record.

When FirstRecord.txt is opened, a BusyFirstRecord.txt is created that 
accomplishes two tasks: all of the existing data from FirstRecord.txt 
is backed-up to BusyFirstRecord.txt, and the latter also serves as a 
temporary block to any subsequent users that try to access 
FirstRecord.txt.  After user-updated data is saved to FirstRecord.txt, 
BusyFirstRecord.txt is then deleted. If there is a problem (i.e. 
user-operated stack crashes or computer problem, etc.), then the 
original data is still available in BusyFirstRecord.txt, which can be 
easily renamed or fixed in a text editor.

This app. is simply a "Rolodex" of accounts receivable; data across 
accounts are not needed; it would be cumbersome (but possible) to do 
calculations by opening/closing all of the accounts in succession using 
the method described above.

So far I've accessed a single group of records concurrently from Mac 
and Windows XP standalones (via VPC), and the mechanism seems to work 
well.  Today I'll try it in the real world and see if I can "break" it.

Kurt

_______________________________________________
use-revolution mailing list
use-revolution at lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution