We are facing a problem with DBISAM. We have two applications.
One running on Delphi with DBISAM Database and the other on VB.NET with SQL Database.
Both are installed on the same Server running Windows Server 2008 R2 + SP2 and the SQL version is SQL Server 2008 R2.
DBISAM - ADD is Version 4.31 (4.31 Build 3) and DBISAM Database Server is Version 4.28 (4.28 Build 6).
There isn't any anti-virus installed on the Machine Server.
In addition, on every User PC Log In we have a scheduled Script that empties the TEMP Folder on the User PC.

The application running on VB.NET and SQL Database, uses the DBISAM Driver to read and write from/to the DBISAM Database (other application).

Sometime, we are facing, on the user PCs, the subject error (DBISAM ENGINE ERROR #10227 Cannot Lock Table or Database Name) on the Delphi application and same on the VB.Net application when both application are running.

We tried to stop the process on writing to the DBISAM Database from the other application but still we are encountering the error from time to time. And most of the time it will require a restart for both applications in order for them to run smoothly again.

Can you please advise what might be causing this and what is the most preferable solution.


Thank you.

Joanna

Joanna,

What is the exact error message you are getting?
Because what you said you are seeing ('Cannot Lock Table or Database Name') doesn't exactly match the error message with code #10227 as it's described in the documentation.
Also, is it an option for you to upgrade everything to version 4.31b3 ?

--
Fernando Dias
[Team Elevate]

Fernando Dias wrote:

Joanna,

What is the exact error message you are getting?
Because what you said you are seeing ('Cannot Lock Table or Database Name') doesn't exactly match the error message with code #10227 as it's described in the documentation.
Also, is it an option for you to upgrade everything to version 4.31b3 ?

--
Fernando Dias
[Team Elevate]

Dear Fernando,

The error message is DBISAM ENGINE ERROR #10229, Transaction Cannot lock the database 'Name'.

Sometimes its , DBISAM ENGINE ERROR #10227 cannot write lock the table 'Name'.

These are the errors we are getting.

We are already using version 4.31b3 unless the DBISAM Database Server has that version, then we have no problem to use it.


Thank you.

Joanna,

The documentation suggests it can be caused by an hardware failure, but it can also be happening because of the way your applications are using table locks and/or transactions, Its hard t guess without further information on what operations are being executed when the error appears. Can you reproduce it using DBSys or with a test application?
Also, I couldn't understand if you are using the latest version or not...

--
Fernando Dias
[Team Elevate]

Joanna,

<< Sometime, we are facing, on the user PCs, the subject error (DBISAM
ENGINE ERROR #10227 Cannot Lock Table or Database Name) on the Delphi
application and same on the VB.Net application when both application are
running. >>

Did this just start happening, or has it always been happening ?  If it just
started happening, then you need to figure out what changed in your
applications that may account for the issue.

Normally, transaction and write lock errors indicate that you have a read
operation that taking too long and holding read locks on tables that other
clients/sessions need to write lock for updates and transaction purposes.
Reporting applications often suffer from this type of problem, especially if
they use un-optimized SQL SELECT statements that end up reading every record
in a table, or most of the records in a table.

--
Tim Young
Elevate Software
www.elevatesoft.com

Dear Tim,

Yes it has been a while we are facing this problem. Isn't there a solution for this?
There are no changes in our applications.
How can I prevent this?


"Tim Young [Elevate Software]" wrote:

Joanna,

<< Sometime, we are facing, on the user PCs, the subject error (DBISAM
ENGINE ERROR #10227 Cannot Lock Table or Database Name) on the Delphi
application and same on the VB.Net application when both application are
running. >>

Did this just start happening, or has it always been happening ?  If it just
started happening, then you need to figure out what changed in your
applications that may account for the issue.

Normally, transaction and write lock errors indicate that you have a read
operation that taking too long and holding read locks on tables that other
clients/sessions need to write lock for updates and transaction purposes.
Reporting applications often suffer from this type of problem, especially if
they use un-optimized SQL SELECT statements that end up reading every record
in a table, or most of the records in a table.

--
Tim Young
Elevate Software
www.elevatesoft.com

Joanna,

<< Yes it has been a while we are facing this problem. Isn't there a
solution for this?  There are no changes in our applications. How can I
prevent this? >>

You have to eliminate the bulk reads on the tables that are involved in
constant transactional updates.  This means either optimizing the SQL used
in the reporting portion of your application, or splitting out archive
tables into another location to be used for reporting purposes.

--
Tim Young
Elevate Software
www.elevatesoft.com