I'm not totally sure I understand even the basics of how databases work.
I view a database as a file that is accessed by programs (be it a server
or a client). The server or client accesses the database and performs
operations on the data. This is essentially how one would use a text
file except that the file can be opened and edited by more than one
person at a time.
If this is the case, do you really need a "server" application that is
sitting somewhere doing nothing but playing traffic cop?
Am I thinking wrong? Please let me know.
I think the reason I'm thinking this way is that I have used "flat
databases" in CGI that are nothing but text files that are accessed and
written to by multiple people via the web. As I type this, I seem to
remember 'lock' files were involved and this is probably exactly what
you are talking about, Jeff.
Thanks for the tip. I should have thought about this simple solution
myself. Duh!
-----Original Message-----
From: Jeff Borckardt [mailto:jeffb at utkux dot utcc dot utk dot edu]
Sent: Tuesday, October 26, 2004 10:26 AM
To: rbnube at mabenterprises dot com; Getting Started
Subject: Re: Multiple users writing to the same file
I have recently been experimenting with exactly the set-up you
describe. Locking and unlocking seems to cause problems because if the
instance of the application that is writing to the datafile locks it
(to indicate to other instances of the application that it's in the
process of being written to), the writing application can't modify it
either.
My work-around (albeit clunky) is that when the application that wants
to write to the central datafile is about to do so, it checks to see if
another file exists called "Wait" (or something). If that file does not
exist, the application creates it, writes to the data file and then
deletes the "Wait" file.
If the "Wait" file does exist when the application is getting ready to
write, it loops and waits (rechecking every second or so) until the
"Wait" file disappears before continuing with writing to the data file.
This way, the presence or absence of the "Wait" file becomes the index
of whether the datafile is being written to by another instance of the
application.
This isn't perfect for a number of reasons, but it might work
well-enough.
Hope this helps,
Jeff
----------
Jeffrey J. Borckardt, Ph.D.
Department of Psychiatry and Behavioral Sciences
Medical University of South Carolina
67 President Street
IOP, 5 South BA 504 E
Charleston, SC 29425
(843)792-3295
borckard at musc dot edu
On Oct 26, 2004, at 2:32 AM, RBNUBE wrote:
> Is there a way for multiple users to read/write to a file at the same
> time? I doubt that this would be possible with a text file, but what
> about a binary file or database?
>
> What I'm picturing in my head is a group of people using individual
> copies of the same application on the same network. The application
> displays data in a list box. The data collected is typical file
> information such as name, size, modification date, etc. This isn't a
> problem. The problem is that the user will be able to customize these
> listings with addition information about these files and everyone
> needs to be aware of this additional information so that they will
> know how to proceed. "This file is to be ignored," "This file is
> ready for further
> action," etc.
>
> If someone edits the information in one of these cells from their copy
> of the application, I would like this new information 'immediately'
> reflected in the application of anyone else viewing the same data. I
> would also like to avoid writing a 'server' application to juggle this
> information the group of 'clients' on the network.
>
> If this in anyway plausible, how would you deal with more than one
> person trying to edit the data and what would be the best way to
> achieve this?
>
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
>
> Search the archives of this list here:
> <http://www.realsoftware.com/listarchives/lists.html>
>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://www.realsoftware.com/listarchives/lists.html>
|