I have a Delphi application running under DBISAM Client/Server 4.29 Build 4. The EXEs (Delphi BDS 2006) are located on each workstation while the Server component is on a separate computer. There is a single LCK file in the database folder, each program has a local session as well that points to a local, private directory.

This application is a conversion of a previous version that did not use a DBISAM server, just DBISAM tables. That program ran pretty well.

There are about 5-6 workstations running and when we upgraded the client to the C/S version they contacted me and said workstations were randomly locking up and receiving "Cannot establish a connection to the server located at...." messages. They had to use the Task Manager to close our program or go into the server and either close sessions or restart the server. When I looked through the server logs I found repeated Error messages of the following form:

3/2/2015 3:51:30 PM [ERROR] Engine error [DBISAM Engine Error # 10258 Cannot lock record in the table 'TTFBH00'] [Client Version: 4.29 User Name: karen Address: 192.168.111.62 Encrypted: No Request: REQUEST_GETCURRECORD Thread: 9336 Session: 64899984]

These are essentially the ONLY error messages in the log, they are all identical. I've checked AV programs on the workstations, making sure they're not set to scan DAT files or monitor our application directories (there don't appear to be any AV programs on the server). The file in questions, TTFBH00, is 63MB in size with a 4MB BLB and is on the one side of a 1-Many relationship. My impression is that this is a size DBISAM can handle, so I haven't looked to purge records that are no longer used.

I realize this information is kind of sketchy but can anyone suggest things to try to get to the bottom of this? As I say, this app worked fine without the server and my clients are looking at me and (implicitly) asking why the h*ll I gave them a server.

Thanks for any info.

On 3/18/2015 8:45 PM, Norman Kleinberg wrote:
> There are about 5-6 workstations running and when we upgraded the client to the C/S version they contacted me and said workstations were randomly locking up and receiving "Cannot establish a connection to the server located at...." messages. They had to use the Task Manager to close our program or go into the server and either close sessions or restart the server. When I looked through the server logs I found repeated Error messages of the following form:
> 3/2/2015 3:51:30 PM [ERROR] Engine error [DBISAM Engine Error # 10258 Cannot lock record in the table 'TTFBH00'] [Client Version: 4.29 User Name: karen Address: 192.168.111.62 Encrypted: No Request: REQUEST_GETCURRECORD Thread: 9336 Session: 64899984]
> These are essentially the ONLY error messages in the log, they are all identical. I've checked AV programs on the workstations, making sure they're not set to scan DAT files or monitor our application directories (there don't appear to be any AV programs on the server). The file in questions, TTFBH00, is 63MB in size with a 4MB BLB and is on the one side of a 1-Many relationship. My impression is that this is a size DBISAM can handle, so I haven't looked to purge records that are no longer used.
>
> I realize this information is kind of sketchy but can anyone suggest things to try to get to the bottom of this? As I say, this app worked fine without the server and my clients are looking at me and (implicitly) asking why the h*ll I gave them a server.

Norman,

Have not run into this myself and we're running dbsrvr with tables a lot
larger so in general DBISAM should have no problem with this table size.

If you search this newsgroup then there were few instances of issues
caused by excessive record locks. Do you know what app is doing when the
error occurs ? (i.e. is it running a large SQL operation like cartesian
join; does the error happen right away or is it after long processing).

Are you using default dbsrvr session timeouts or something more aggressive.

AV you said is not a concern so next thing i would look at is server
windows error logs and make sure it's not running low on resources.

I'd also check the usual suspects like network connectivity (especially
if clients are on wireless) and things like whether client computers
might go to sleep with app active just in case also.

Raul

Norman


>3/2/2015 3:51:30 PM [ERROR] Engine error [DBISAM Engine Error # 10258 Cannot lock record in the table 'TTFBH00'] [Client Version: 4.29 User Name: karen Address: 192.168.111.62 Encrypted: No Request: REQUEST_GETCURRECORD Thread: 9336 Session: 64899984]
>
>These are essentially the ONLY error messages in the log, they are all identical

First thing I'd suspect (because its easy and quick) is the table. Have you tried repairing it? If its OK is there a specific record that everyone goes for which could result in unhandled contention?

Next would be program logic. Since its always the same table have a look at where it is locked.

Unless your "identical" is literal have a look at the logs and see it there's a pattern to the failure eg is it always Karen who starts it? If its hardware related that could also give a clue as to which workstation(s). If the "identical" is literal then what is Karen doing that is different.

I assume you also have other sites running the c/s version - any obvious differences?

Roy Lambert

Roy Lambert wrote:

Norman


>3/2/2015 3:51:30 PM [ERROR] Engine error [DBISAM Engine Error # 10258 Cannot lock record in the table 'TTFBH00'] [Client Version: 4.29 User Name: karen Address: 192.168.111.62 Encrypted: No Request: REQUEST_GETCURRECORD Thread: 9336 Session: 64899984]
>
>These are essentially the ONLY error messages in the log, they are all identical

First thing I'd suspect (because its easy and quick) is the table. Have you tried repairing it? If its OK is there a specific record that everyone goes for which could result in unhandled contention?

Next would be program logic. Since its always the same table have a look at where it is locked.

Unless your "identical" is literal have a look at the logs and see it there's a pattern to the failure eg is it always Karen who starts it? If its hardware related that could also give a clue as to which workstation(s). If the "identical" is literal then what is Karen doing that is different.

I assume you also have other sites running the c/s version - any obvious differences?

Roy Lambert

Roy:

No, it is (sort of) literal. Exactly the same message except for the user involved that varies. My other sites don't report this at all. I did verify the table (it was fine) and optimized it, I even purged it of old records to reduce the size by half. I don't expect this will have any effect. I don't know if it's the same record, let me look at the logic, I do have an idea of at least one operation that triggered the error. The problem is that this operation was done all the time with the non-server version (they used it for almost ten years) without issue.

Thanks.

Norman


>No, it is (sort of) literal. Exactly the same message except for the user involved that varies. My other sites don't report this at all. I did verify the table (it was fine) and optimized it, I even purged it of old records to reduce the size by half. I don't expect this will have any effect. I don't know if it's the same record, let me look at the logic, I do have an idea of at least one operation that triggered the error. The problem is that this operation was done all the time with the non-server version (they used it for almost ten years) without issue.

What that says to me is two things (both might be wrong)

1: if its a network hardware problem its more likely to be at the server end rather than the workstation end
2: its not one moron (might be two or more) carrying out some weird sequence of actions, however, we did have one of those in my last line role - he could lock up a dozen terminals before anyone else arrived at work


Can you tell us what was the operation you know causes the problem? It may give someone a brainwave.

Roy Lambert

Raul wrote:

Have not run into this myself and we're running dbsrvr with tables a lot
larger so in general DBISAM should have no problem with this table size.

If you search this newsgroup then there were few instances of issues
caused by excessive record locks. Do you know what app is doing when the
error occurs ? (i.e. is it running a large SQL operation like cartesian
join; does the error happen right away or is it after long processing).

Are you using default dbsrvr session timeouts or something more aggressive.

AV you said is not a concern so next thing i would look at is server
windows error logs and make sure it's not running low on resources.

I'd also check the usual suspects like network connectivity (especially
if clients are on wireless) and things like whether client computers
might go to sleep with app active just in case also.

Raul

Raul:

I'm going to look at my session timeouts but I believe I'm using the default (I believe 300 secs.). What happens is that we execute a (live) query that we subsequently put into edit mode, then either save or cancel. The many sides of the relationship are cached (via CachedUpdates) at the client side so that if we cancel then they can be discarded. From the error message I'm inferring that the lock can't be obtained when the query is put into edit mode, but I'm not sure. I'm going to inspect the code and see what's going on, might have to insert some error-checking code. The fact that it's (essentially) the same message on the same file makes me feel a bit less uneasy, this should make it easier to track down the problem. I still have a message into their IT guy who insists there is VIPRE AV on the server, but I don't think that if it were the AV I'd see problems like this. Who knows? Like with a lot of things, once the problem is discovered you go "of COURSE, that makes sense, why didn't I think of it sooner?". Before-the-fact it's inscrutable.

Thanks for posting and trying to help me out.

Norman

Raul wrote:

Norman,

Have not run into this myself and we're running dbsrvr with tables a lot
larger so in general DBISAM should have no problem with this table size.

If you search this newsgroup then there were few instances of issues
caused by excessive record locks. Do you know what app is doing when the
error occurs ? (i.e. is it running a large SQL operation like cartesian
join; does the error happen right away or is it after long processing).

Are you using default dbsrvr session timeouts or something more aggressive.

AV you said is not a concern so next thing i would look at is server
windows error logs and make sure it's not running low on resources.

I'd also check the usual suspects like network connectivity (especially
if clients are on wireless) and things like whether client computers
might go to sleep with app active just in case also.

Raul

Just some additional info, I've looked at the Windows error logs and the only consistent anomalies is a DCOM error that says that the server can't communicate with the "karen-pc" by any known protocols (or words to that effect, don't remember exactly). This appears to occur about 20-30 times a day, at least. I suppose that is not necessarily connected with this problem as other users are affected, but it does seem to show something's amiss.

On 3/19/2015 12:58 PM, Norman Kleinberg wrote:
> Just some additional info, I've looked at the Windows error logs and the only consistent anomalies is a DCOM error that says that the server can't communicate with the "karen-pc" by any known protocols (or words to that effect, don't remember exactly). This appears to occur about 20-30 times a day, at least. I suppose that is not necessarily connected with this problem as other users are affected, but it does seem to show something's amiss.

Norman,

One reference i found was https://support.microsoft.com/en-us/kb/957713
 and this could be something as simple as PC firewall not allowing
admin connections (especially if they use non-Microsoft Firewall - maybe
even as part of AntiVirus).

Hence i personally would say this is something unrelated but one never
knows.

Raul

Raul wrote:

On 3/19/2015 12:58 PM, Norman Kleinberg wrote:
> Just some additional info, I've looked at the Windows error logs and the only consistent anomalies is a DCOM error that says that the server can't communicate with the "karen-pc" by any known protocols (or words to that effect, don't remember exactly). This appears to occur about 20-30 times a day, at least. I suppose that is not necessarily connected with this problem as other users are affected, but it does seem to show something's amiss.

Norman,

One reference i found was https://support.microsoft.com/en-us/kb/957713
 and this could be something as simple as PC firewall not allowing
admin connections (especially if they use non-Microsoft Firewall - maybe
even as part of AntiVirus).

Hence i personally would say this is something unrelated but one never
knows.

Raul

Nice of you to search this out. As I say, this shouldn't be connected to my original problem since the record locking, etc., doesn't occur over as admin connection, but I'll point their IT guy to it.

One thing I've noted is that the occurrence of the locking errors has diminished markedly since I pared the file size down, perhaps that's a clue.

Thanks.

On 3/19/2015 2:02 PM, Norman Kleinberg wrote:
> One thing I've noted is that the occurrence of the locking errors has diminished markedly since I pared the file size down, perhaps that's a clue.

DBISAM i believe uses OS for low level locking so there might be a limit
you're hitting - i'd definitely try to get to the bottom of the
query/operation that is being run and see what's going on (how big is
the resultset etc).

Note that last entry about this in newsgroups was some 5 years back so
this is pure speculation in my part and might be something completely
different.

If you do need a faster response you should consider contacting support
direct - i recall Tim had a special debug version of dbsrvr so that
might help pinpoint issue even faster (since you're still seeing these
events on a daily basis).

Raul