Attempted Simultaneous Access causes "Could not lock file"

I have a screen scraper written in perl that populates the same database
every night with new additional information.

Why is it that when I try to simultaneously write to the database with perl
and read it with my ASP.NET UI I get "could not lock file" from ASP.NET?

Thanks,
Siegfried

Siegfried Heintze wrote:

I have a screen scraper written in perl that populates the same database
every night with new additional information.

Why is it that when I try to simultaneously write to the database with perl
and read it with my ASP.NET UI I get "could not lock file" from ASP.NET?

Thanks,
Siegfried

I don't know the details of your system, but this behavior seems quite
reasonable. If ASP.NET needs exclusive use of some resource (such as
your database), and some other process currently has access to the
resource, then ASP.NET should definitely have to wait until nobody else
is using it. Maybe you can schedule the activities for different times.

-- Vincent Johns
Please feel free to quote anything I say here.

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.

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 understand that the MSAccess GUI needs exclusive access when editing a
table definition, but I'm not doing that.

Thanks,
Siegfried


"Vincent Johns" wrote in message
k.net...
Siegfried Heintze wrote:

I have a screen scraper written in perl that populates the same database
every night with new additional information.

Why is it that when I try to simultaneously write to the database with
perl
and read it with my ASP.NET UI I get "could not lock file" from ASP.NET?

Thanks,
Siegfried

I don't know the details of your system, but this behavior seems quite
reasonable. If ASP.NET needs exclusive use of some resource (such as
your database), and some other process currently has access to the
resource, then ASP.NET should definitely have to wait until nobody else
is using it. Maybe you can schedule the activities for different times.

-- Vincent Johns
Please feel free to quote anything I say here.

Siegfried Heintze wrote:

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.

Thanks,
Siegfried


"Vincent Johns" wrote in message
k.net...

Siegfried Heintze wrote:


I have a screen scraper written in perl that populates the same database
every night with new additional information.

Why is it that when I try to simultaneously write to the database with

perl

and read it with my ASP.NET UI I get "could not lock file" from ASP.NET?

Thanks,
Siegfried

I don't know the details of your system, but this behavior seems quite
reasonable. If ASP.NET needs exclusive use of some resource (such as
your database), and some other process currently has access to the
resource, then ASP.NET should definitely have to wait until nobody else
is using it. Maybe you can schedule the activities for different times.

-- Vincent Johns
Please feel free to quote anything I say here.

Thanks for your thoughful response, Vincent.

Presently I have one of the perl programs running collecting data and
storing it in my MSAccess database. It has been running since 11PM last
night.

I just wrote another test perl program and pasted in the massive SELECT
statement from my C# aspx code into the perl test code. The perl test code
runs fine.

Can we infer from this test that there is nothing wrong with the perl code
and there is something in my C#/ASPX connection string that needs
adjustment?

I also tried convering my aspx from ole to odbc. This did not help. The
symptoms are the same: no problem as long as perl is not writing to the
database.

Is this behavior new? Hmmm.... I've never been able to make simultaneous
access work between C# and Perl.

Any thoughts?

Thanks,
Siegfried


"Vincent Johns" wrote in message
ink.net...
Siegfried Heintze wrote:

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.

Thanks,
Siegfried


"Vincent Johns" wrote in message
k.net...

Siegfried Heintze wrote:


I have a screen scraper written in perl that populates the same
database
every night with new additional information.

Why is it that when I try to simultaneously write to the database with

perl

and read it with my ASP.NET UI I get "could not lock file" from
ASP.NET?

Thanks,
Siegfried

I don't know the details of your system, but this behavior seems quite
reasonable. If ASP.NET needs exclusive use of some resource (such as
your database), and some other process currently has access to the
resource, then ASP.NET should definitely have to wait until nobody else
is using it. Maybe you can schedule the activities for different times.

-- Vincent Johns
Please feel free to quote anything I say here.

Siegfried Heintze wrote:

Thanks for your thoughful response, Vincent.

Presently I have one of the perl programs running collecting data and
storing it in my MSAccess database. It has been running since 11PM last
night.

I just wrote another test perl program and pasted in the massive SELECT
statement from my C# aspx code into the perl test code. The perl test code
runs fine.

Can we infer from this test that there is nothing wrong with the perl code
and there is something in my C#/ASPX connection string that needs
adjustment?

I'm not familiar enough with either ASPX or Perl to give much advice
here, but it still looks like a locking problem to me. Can you get ASPX
to give you more detailed information about exactly what went wrong?

I also tried convering my aspx from ole to odbc. This did not help. The
symptoms are the same: no problem as long as perl is not writing to the
database.

Can you get the Perl program to release its control of the database on a
periodic basis (such as once every five seconds) to let other processes
such as ASPX access it?

-- Vincent Johns
Please feel free to quote anything I say here.

Is this behavior new? Hmmm.... I've never been able to make simultaneous
access work between C# and Perl.

Any thoughts?

Thanks,
Siegfried

Vincent,

I coded yet another ASP.NET web page using odbc instead of OleDB and used a
datareader instead of an adapter.

I die when I try to open the connection.
Here is the error message that only occures when the Perl program is
running:

ERROR [HY000] [Microsoft][ODBC Microsoft Access Driver]General error Unable
to open registry key 'Temporary (volatile) Jet DSN for process 0x1454 Thread
0x12b0 DBC 0x158128c Jet'. ERROR [IM006] [Microsoft][ODBC Driver Manager]
Driver's SQLSetConnectAttr failed ERROR [HY000] [Microsoft][ODBC Microsoft
Access Driver]General error Unable to open registry key 'Temporary
(volatile) Jet DSN for process 0x1454 Thread 0x12b0 DBC 0x158128c Jet'.
ERROR [HY000] [Microsoft][ODBC Microsoft Access Driver] Could not use
'(unknown)'; file already in use. ERROR [HY000] [Microsoft][ODBC Microsoft
Access Driver]General error Unable to open registry key 'Temporary
(volatile) Jet DSN for process 0x1454 Thread 0x12b0 DBC 0x158128c Jet'.
ERROR [HY000] [Microsoft][ODBC Microsoft Access Driver]General error Unable
to open registry key 'Temporary (volatile) Jet DSN for process 0x1454 Thread
0x12b0 DBC 0x158128c Jet'. ERROR [HY000] [Microsoft][ODBC Microsoft Access
Driver] Could not use '(unknown)'; file already in use.

Thanks,
Siegfried

P.S.Here is the connection string:
Driver={Microsoft Access Driver
(*.mdb)};Dbq=C:\Inetpub\heintze\keyword-job-search\job-search-usa.mdb;Uid=Ad
min;Pwd=;"


"Vincent Johns" wrote in message
ink.net...
Siegfried Heintze wrote:

Thanks for your thoughful response, Vincent.

Presently I have one of the perl programs running collecting data and
storing it in my MSAccess database. It has been running since 11PM last
night.

I just wrote another test perl program and pasted in the massive SELECT
statement from my C# aspx code into the perl test code. The perl test
code
runs fine.

Can we infer from this test that there is nothing wrong with the perl
code
and there is something in my C#/ASPX connection string that needs
adjustment?

I'm not familiar enough with either ASPX or Perl to give much advice
here, but it still looks like a locking problem to me. Can you get ASPX
to give you more detailed information about exactly what went wrong?

I also tried convering my aspx from ole to odbc. This did not help. The
symptoms are the same: no problem as long as perl is not writing to the
database.

Can you get the Perl program to release its control of the database on a
periodic basis (such as once every five seconds) to let other processes
such as ASPX access it?

-- Vincent Johns
Please feel free to quote anything I say here.

Is this behavior new? Hmmm.... I've never been able to make simultaneous
access work between C# and Perl.

Any thoughts?

Thanks,
Siegfried

Sorry, I've not seen this message and am not familiar enough with Perl
to help.

Have you checked Microsoft's Web site for these kinds of errror? (They
still look like a locking conflict to me, but I can't say much beyond that.)

-- Vincent Johns
Please feel free to quote anything I say here.

Siegfried Heintze wrote:

Vincent,

I coded yet another ASP.NET web page using odbc instead of OleDB and used a
datareader instead of an adapter.

I die when I try to open the connection.
Here is the error message that only occures when the Perl program is
running:

ERROR [HY000] [Microsoft][ODBC Microsoft Access Driver]General error Unable
to open registry key 'Temporary (volatile) Jet DSN for process 0x1454 Thread
0x12b0 DBC 0x158128c Jet'. ERROR [IM006] [Microsoft][ODBC Driver Manager]
Driver's SQLSetConnectAttr failed ERROR [HY000] [Microsoft][ODBC Microsoft
Access Driver]General error Unable to open registry key 'Temporary
(volatile) Jet DSN for process 0x1454 Thread 0x12b0 DBC 0x158128c Jet'.
ERROR [HY000] [Microsoft][ODBC Microsoft Access Driver] Could not use
'(unknown)'; file already in use. ERROR [HY000] [Microsoft][ODBC Microsoft
Access Driver]General error Unable to open registry key 'Temporary
(volatile) Jet DSN for process 0x1454 Thread 0x12b0 DBC 0x158128c Jet'.
ERROR [HY000] [Microsoft][ODBC Microsoft Access Driver]General error Unable
to open registry key 'Temporary (volatile) Jet DSN for process 0x1454 Thread
0x12b0 DBC 0x158128c Jet'. ERROR [HY000] [Microsoft][ODBC Microsoft Access
Driver] Could not use '(unknown)'; file already in use.

Thanks,
Siegfried

P.S.Here is the connection string:
Driver={Microsoft Access Driver
(*.mdb)};Dbq=C:\Inetpub\heintze\keyword-job-search\job-search-usa.mdb;Uid=Ad
min;Pwd=;"