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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kurt Kaufman Sent: Tuesday, April 26, 2005 7:59 AM To: use-revolution@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@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution