Siegfried said:
Hmmm.... the ASP.NET application is only reading.
I can have multiple perl programs writing to the database, simultaneously. I
wrote both programs. One of the most important features of a database, I
thought, was simultaneous access by multiple processes.
No. Any simultaneous "write" access is only to different parts of the
same database, such as separate records. If two processes attempt
simultaneous changes to the same field, someone's work is likely to be
trashed -- the field will contain only one value at the end, regardless
of how many processes tried to change it.
In Access, multiple processes might access separate records, but any one
record is modifiable by only one process at a time, and it must release
the record before the other process can change it. (It often doesn't
even make sense for the 2nd process to have read-only access to the
record, as the fields could easily be inconsistent up to the time the
1st process finishes writing and releases the record lock.)
The perl code is just doing "INSERT"s and the ASP.NET is only doing Selects.
Is there not some setting that needs to be adjusted to allow multiple
readers and writers?
I don't know, but my guess is that Perl needs to explicitly release each
record after it finishes writing that record. Perhaps it's neglecting
to unlock records.
Is all this behavior new? If it is, did you change some of the code
just before you noticed it? You might want to return to a previous
version to try to identify the cause of the problem.
I understand that the MSAccess GUI needs exclusive access when editing a
table definition, but I'm not doing that.
It probably needs exclusive access to the entire Table if it's modifying
the Table's structure! I'd want exclusive access to the entire database
if I were doing that, and for long enough to check the results for
accuracy and consistency.
But for editing the contents of a set of records, you probably need
exclusive access only to the records being modified. Are you defining
transactions on which you may at times perform Commit or Rollback
operations? Any resources (e.g. records in Tables) involved in those
will temporarily belong exclusively to some process, I expect.
If the ONLY operation that any process wants to perform is reading, then
there shouldn't be any need for any exclusive access. But you said that
the Perl code is writing, too, so it does need to exclude other
processes. I think the main question is how it's accomplishing that,
and under what conditions it allows other processes to read.