Hello everyone,

I have a 3rd party application from a company that is now out of business that we use on a 32-bit Windows XP Professional machine that uses DBISAM.  The application works fine on the Windows XP machine, but whenever we run it on the 32-bit Windows 7 Professional machine it gives problems.  A few transactions at a time and its fine, but when we run it overnight it tends to get lots of transactions back to back, and thats when it locks up.  

The debug log shows things like this:

[quote]
Exception calling WriteTerminalData: DBISAM Engine Error # 10242 Cannot unlock table or record in the table 'TableName'
[/quote]

And this:

[quote]
Error in BuildTerminalResponsePacket: List index out of bounds (0)

Sending Response Packet: HOST ERROR 105
[/quote]

After reading here:
http://www.elevatesoft.com/forums?action=view&category=dbisam&id=dbisam_general&msg=64778&page=5

It seemed that I just needed to verify and repair the table.  I found a copy that would open the version 3.0 DBISAM databases, and it still gives a similar problem.  While I know this is a bit vague, since the application is not yours, I was wondering if someone could shed some light on any known issues migrating from Windows XP to Windows 7 (both 32-bit) with a version 3.0 DBISAM database.

It might also be worth noting that I've disabled UAC completely and am running the programs as an Administrator.

I also wanted to clarify that I used:

DBISAM Additional Software and Utilities V3
-> Database System Utility

To verify and repair the tables.  The latest version of the additional software and utilities wouldn't open the database, and if I upgrade the database to the newest version the program doesn't work at all (I would assume since its designed for version 3.0).  It pretty much works, with the exception of locking up with lots of transactions (or maybe certain ones, it happens overnight so I can't say for sure), which is why I posted here in the first place to see if there's something I'm doing wrong on the database migration.  

Thanks!

jwright8

I see where you're coming from with the ng reference but I think its a bit more serious than a simple repair. Looking at the V4 manual I find

DBISAM_UNLOCKFAILED (10242) Cannot unlock the table or record in the table '<TableName>'
This error occurs when DBISAM cannot unlock a record in a table or the entire table itself. This error should never occur so if it does you should contact Elevate.

My suggestion would be to contact ElevateSoft support directly (these are peer supported newsgroups even though Tim does pop his head up every so often) explain the problem and be willing to pay for support. I can't remember if there were any breaking changes with V3 so I don't know which version of the utilities you'll need. I do have 3.29 (I've dumped all the rest) so if you want to email me the tables I can check out to see if they are corrupt, but you are better off contacting Tim.

I've also just thought of a very suggested thing which is to disable anti-virus. That's often associated with various problems. I'm not saying that's the case here just that its worth a check, especially if it changed between the XP and the W7 machines.

I don't suppose you either have, or can obtain the source for the app?

Roy Lambert [Team Elevate]

Roy,

Thanks for the quick reply.  I had also disabled antivirus on the system for testing (I had thought something along those lines as well), I had just forgotten to mention it in my post.

The confusing thing about the cannot unlock error is that it only tends to happen when repeated operations happen in a row, and suddenly it locks.  Doing one operation alone will not pose a problem.  The reason it's odd is that you'd think that if there was some type of table error or corruption that it would happen regardless of the frequency of operations on the table.  Another reason is the fact that it continues to work perfectly on the Windows XP system that is still running it.  

I tried both V4 and V3 of the utility.  V4 wouldn't open the table at all (optimize, verify, repair, or even viewing it wouldn't work), other than to "Upgrade" it.  The program wouldn't read correctly from the updated table, so that doesn't seem to be a viable option.  V3 is the one I was able to use to run the Verify and Repair operations on the table.  I can e-mail you the table if you'd like to see if you can see any corruption (it's not sensitive data or anything).

Unfortunately I don't have the source for the application.  I am still trying to contact the company, but I don't really have any hope that I'll be able to get any help, or even a response, from them.  

Thanks for the help so far.

On 7/9/2013 9:50 AM, jwright8 wrote:
> The confusing thing about the cannot unlock error is that it only tends to happen when repeated operations happen in a row, and suddenly it locks.  Doing one operation alone will not pose a problem.  The reason it's odd is that you'd think that if there was some type of table error or corruption that it would happen regardless of the frequency of operations on the table.  Another reason is the fact that it continues to work perfectly on the Windows XP system that is still running it.

Might be OS related or could always be a problem with the app itself (on
how it accesses data).

You did not mention this but is the data local to the machine - vista
and win7 really screwed up the network file sharing (microsoft problem)
to the point that it's almost unusable and one needs to use
client/server now even on small LANs.

Few other things i would suggest (you might have already done so):

- make sure your file permissions are OK (especially if it's installed
in "program files" folder). For older apps i always suggest doing a new
folder without spaces off the root of drive if possible (e.g. c:\myapp)
and set full permissions for users.

- enable the compatibility mode (open exe properties and under
compatibility tab set it XP SP2 or SP3 mode).

- depends one the app but sometimes working folder permissiosn could
cause problems in newer windows so might be worthwhile to run the app
from a link that sets teh working folder to apps own exe folder

Raul

jwright8

>Thanks for the quick reply. I had also disabled antivirus on the system for testing (I had thought something along those lines as well), I had just forgotten to mention it in my post.

Ah well it was worth a thought.

>The confusing thing about the cannot unlock error is that it only tends to happen when repeated operations happen in a row, and suddenly it locks. Doing one operation alone will not pose a problem. The reason it's odd is that you'd think that if there was some type of table error or corruption that it would happen regardless of the frequency of operations on the table.

Well you might. Ages ago I had a problem with a multi-threaded application that bombed intermittently it seemed. In fact it bombed every tiime a particular set of circumstances happened (infrequently and almost randomly). It took a lot of time and work before I managed to put a demo together where it happened every time so Tim could fix it.

>Another reason is the fact that it continues to work perfectly on the Windows XP system that is still running it.

So that, taken in conjunction with the fact that a repair didn't cure things, suggests that there is some difference between the XP and X7 system.

>I tried both V4 and V3 of the utility. V4 wouldn't open the table at all (optimize, verify, repair, or even viewing it wouldn't work), other than to "Upgrade" it. The program wouldn't read correctly from the updated table, so that doesn't seem to be a viable option. V3 is the one I was able to use to run the Verify and Repair operations on the table. I can e-mail you the table if you'd like to see if you can see any corruption (it's not sensitive data or anything).

Not too much point if you've tried it and it hasn't worked.

>Unfortunately I don't have the source for the application. I am still trying to contact the company, but I don't really have any hope that I'll be able to get any help, or even a response, from them.

How complex is it? Depending on licences / contract it might be worth having someone see if they can reverse engineer it.

I assume that if you just move things back to an XP machine every things fine. If not I did have the thought of using DBSys to reverse engineer the tables with data and see if that's any better. However, at this point in time, and with what you've posted I'd definitely suggest contacting Elevate support directly.

Roy Lambert [Team Elevate]

Raul

>Might be OS related or could always be a problem with the app itself (on
>how it accesses data).

That raises an interesting question - has the data changed in any weird way since the move from XP to W7?

>You did not mention this but is the data local to the machine - vista
>and win7 really screwed up the network file sharing (microsoft problem)
>to the point that it's almost unusable and one needs to use
>client/server now even on small LANs.

Why, I don't know, but I'd been assuming either f/s on one machine or c/s.

>- enable the compatibility mode (open exe properties and under
>compatibility tab set it XP SP2 or SP3 mode).

That's a very good suggestion. I don't know what differences it makes but its got to be worth a try.

Roy Lambert [Team Elevate]

jwright8


Forgot to suggest, just in case its not DBISAM / your application holding the lock, download Process Explorer (somewhere on the MS site), or Unlocker from http://www.emptyloop.com/unlocker/ and see what they tell you.

Roy Lambert [Team Elevate]

Thanks for the replies, I'll try to address all the suggestions.

The data files are stored locally on the drive.  I've checked the permissions as well (I've also tried opening it up to everyone/anonymous/etc for testing purposes).  I don't think I have tried compatibility mode.. I can't honestly remember, but I will try that and see what happens.  

The app works in folders off the C: drive (not Program Files).  The file structure is actually (intentionally) identical to the Windows XP system.

The fact that it does still work on the XP system without a problem also leads me to believe there's some kind of OS difference.  I'll re-check the folder permissions like Raul suggested (in case I goofed something up) and try the compatibility mode.  

The app is fairly simple in what DBISAM does... the other functions might be a bit more complicated.  If it seemed like it was going to be an OS problem, I'm half tempted to try it on another Windows XP system to see if it presents the same problem... that will likely be the next step if the folder permissions or compatibility mode don't do anything for me.  

Thanks to you both for the help so far.