Using DBISAM 4.29 build 2 in Delphi 2006.

Customer system has been up and running for a year or more, on Win2008 Server.

Out of the blue, is getting error:

DBISAM 10229 Transaction cannot lock the database

We have rebooted the server, and reindexed the db... and nothing solves.

What can cause this?
What steps should we take?

Hi Rafael,

A couple of thoughts that come to mind that might be worth checking:

- Do you have sufficient drive space available where the datafiles and
tempdir are located?

- Maybe re-apply all permissions so all users have full access incase
Windows has done something funky with the permissions on the file?

Hope this helps...

Adam.

Thanks!

We know that the user has permissions. The app often works.... once (which involves read / writes / append to dbisam).

But this machine has been working, and now there is this issue.

I tried using process explorer (sysinternals) to see what was touching dbisam.lck, but nothing suspicious.

Where to look for the issue?

samjones4


My money would go on AV software

Roy Lambert

Rafael,

<< Out of the blue, is getting error:

DBISAM 10229 Transaction cannot lock the database

We have rebooted the server, and reindexed the db... and nothing solves. >>

Has anything new been installed or anything existing been updated on the server machine/OS ?

Has there been an influx of more users, or has the volume of activity increased significantly for the installation ?

Tim Young
Elevate Software
www.elevatesoft.com

>> Has anything new been installed or anything existing been updated on the server machine/OS ?

No, the machine is really very clean.

>> Has there been an influx of more users, or has the volume of activity increased significantly for the installation ?

No. We can see the problem with just 1-2 users (they normally have 4 at most), and very very little db traffic.

The machine does have the kaspersky AV on it.

I was also told, this morning, that the problem is most quickly seen when connecting through the dbisam server (which is in our nt service application), and not seen when connecting to the db directly (from user session app).

Could the AV be jumping on temp files under \windows\ more than it does under \users\ ?

(Heck, can AV even cause this? And if so, what file(s) should I look at in process explorer, since I never saw the AV touch the main dbisam.lck -- e.g. not the one in the db dir)

Or ?

> No. We can see the problem with just 1-2 users (they normally have 4 at most), and very very little db traffic.
>
> The machine does have the kaspersky AV on it.
>
> I was also told, this morning, that the problem is most quickly seen when connecting through the dbisam server (which is in our nt service application), and not seen when connecting to the db directly (from user session app).
>
> Could the AV be jumping on temp files under \windows\ more than it does under \users\ ?
>
> (Heck, can AV even cause this? And if so, what file(s) should I look at in process explorer, since I never saw the AV touch the main dbisam.lck -- e.g. not the one in the db dir)
>
> Or ?

AV can definitely cause this type of stuff.

If you're able to produce the error on demand, you could try disabling
the AV and then do a few transactions, and see if that resolves the issue.

If this works, you could also try excluding all file extensions
associeated with dbisam (.lck, .dat, .idx .blb .dbk, .ibk, .bbk) from
live antivirus scans to see if that resolves the issue.

If everything was working and it's suddenly stopped then my money would
be on something on the machine that automatically updates itself. Either
a Windows update, or as Roy as commented - more likely an antivirus
update that has changes to the way it handles things.

HTH

Adam.

Thanks all!

We are chasing hard on the AV path. There may be some progress.

<< No. We can see the problem with just 1-2 users (they normally have 4 at most), and very very little db traffic. >>

That indicates something environmental.

<< The machine does have the kaspersky AV on it.

I was also told, this morning, that the problem is most quickly seen when connecting through the dbisam server (which is in our nt service application), and not seen when connecting to the db directly (from user session app).

Could the AV be jumping on temp files under \windows\ more than it does under \users\ ? >>

Well, in most cases the temporary files for a direct connection would be created on the *local machine's* drive, not on the shared drive of the server machine.  So, the AV software on the server machine wouldn't touch it.

I suspect that the issue is related to delays being caused by the AV software scanning file opens/creates/deletes on database files, which is having the knock-on effect of causing transactions to hold on to database locks much longer than normally would be the case, resulting in the errors that you're seeing.

Tim Young
Elevate Software
www.elevatesoft.com