Have a product that has been working for years without any issues, then this week I have multiple customers stating they are now getting the DBISAM Engine Error #11013 Access Denied.  

They all seem to be running W10, and the DBISAM is version 4.29 Build 4.

The lock file is created and deleted in their AppData folder that contains their data files.  It says it is being created and deleted at close of program as it should, but getting this error.

All that have reported this so far has different Antivirus software installed and had them turn off their AV to see if that caused the issue, but has not as it still came up with the error.

I have had them backup their data files and sent them to me, no issues with the files, I even restored them onto my system and ran the software without errors.

Thought occurred to me that it might be a W10 update this week that could be causing something, but the software runs fine on all of my W10 machines.

Used D6 and DBISAM 4.29 Build 4.

There are thousands of users running the software, so it has me a bit on the worried side.

Any thoughts or ideas?

Christopher


Looking at the DBISAM manual it seems that this is an exclusivity thing. If you're opening a table exclusively it could be that its not being released properly. Anti-virus and sharing issues as you say have often given rise to these sort of problems. The fact that they are running different av software doesn't prevent this being the problem and it may even be Windows Defender (or whatever its called in W10) that's the problem.

Questions:

1. Do you know which is the affected table in each instance?
2. Are the programs c/s or f/s?
3. Is it LAN or local?
4. Are you doing anything to tables in exclusive mode (eg repair, restructure, optimise)?

Roy Lambert

I have tested a few things on my machine in reference to your ideas and here is what I did.

I believe this is not an exclusivity issue, here is why.
I opened the software, then opened the associated files with the Database System Utility. I even went and modified a record in each of the files while the software program was still running, no errors.
I ran the software and left it up running.  Logged onto the same machine as a standard user account, ran the software there (which I changed the data files location so both users can access the data files) ran fine, as they both were sharing the same files. No errors.
I logged onto one of the customers machine that was getting the error...
Ran the software, it came up with the error - DBISAM Engine Error #11013 Access Denied - "64960"
So it did not show a file name that the issue was associating with.  The program came up and could process information in the files which were opened, but every data transaction gave the same error message and code. But, the transaction did process and the data files were updated.  
Exited the program, ran again and the same error message came up but with a different last number "31240", then tried again and came up with "58720". Just to give the pattern.
Customer installed software onto their laptop, ran fine no errors.  Restored the files from the desktop, ran fine no errors.
The customer shuts the machine in question down everynight so cannot be issues holding files.
Now the laptop we installed the software on has the same AV software on it and W10.  Only difference may be that the last Windows update has not been installed, since it has not been powered on since Monday a couple days ago. (not sure, as the customer will check for updates and install if there are any and will get back to me if issues on the laptop.)

So have determined the problem is not in the data files themselves or sharing, or permissions as I check that also (he was an Admin on the machine and no other users on the machine.

This is a desktop application, not a C/S app.  Not on a lan, or accessed that way.
There is not exclusivity in the program except to build the files on first run.  Which of course is not firing at this time.

Hope this all helps explain.  As I am stumped.  Any suggestions would be appreciated.

On 12/17/2015 11:11 AM, Christopher Starre wrote:
> Ran the software, it came up with the error - DBISAM Engine Error #11013 Access Denied - "64960"
> So it did not show a file name that the issue was associating with.

The "64960" is likely the filename - what you're seeing here are the
temp files that are created as part of non-live queries and such.

The issue is most likely with the "privatedir" path in the session
object(s). Are you setting the "privatedir" property in your app ?

As of DBISAM 4.30 build 5 this is auto-defaulted to users temp folder
but anything before you need to set it (or end up with possibly
undesirable default)

Raul

Christopher


I agree with Raul - it looks like a temporary files issue. That brings us back to permissions or anti-virus, and I would bet permissions or PrivateDir pointing to a drive / directory that doesn't exist.

Roy Lambert

Christopher,

Do you have access to one of the machines that is experiencing the issue ?  If so, then you can run Process Monitor:

https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx

on their machine and see what, if anything, is blocking the DBISAM file access.  You would basically set up a filter in ProcMon on the DBISAM table file name in question (<TableName>.dat), and then you'll see all file I/O activity related to that file on the machine.

That will tell you exactly what is messing with the table file that is preventing access.  If the only process that is accessing the table file is your application, then most likely it's a Windows permissions issue with the containing folder or the files themselves.

Tim Young
Elevate Software
www.elevatesoft.com

Thanks for all the help. I wish I could determine the actual fix.  I upgraded the DBISAM to the latest version, recompiled and distributed the software.  On one of the customers that was having the issue, it seemed to correct everything and they are back up and running fine.  Another one came back to me before updating and stated that another W10 update seemed to correct the issue.  So, not exactly sure, but happy nonetheless.  I believe it was the temporary file location issue, as the lock file was fine being built in the data folder of the pgm, but it appears a couple of temporary files were also being created and those were not specified as to where they were to be created, so I am going to assume that the upgrade of db solved this issue.

Thanks again for the help, will log this on in the brain for future reference.
Chris

Christopher Starre wrote:

Thanks for all the help. I wish I could determine the actual fix.  I upgraded the DBISAM to the latest version, recompiled and distributed the software.  On one of the customers that was having the issue, it seemed to correct everything and they are back up and running fine.  Another one came back to me before updating and stated that another W10 update seemed to correct the issue.  So, not exactly sure, but happy nonetheless.  I believe it was the temporary file location issue, as the lock file was fine being built in the data folder of the pgm, but it appears a couple of temporary files were also being created and those were not specified as to where they were to be created, so I am going to assume that the upgrade of db solved this issue.

Thanks again for the help, will log this on in the brain for future reference.
Chris
-----------------------

Chris,

Whenever I encounter this error I find it is because I have the table pre-marked as Read Only and don't notice it and then try to do a Write operation to it.

FWIW.

Jerry

Christopher Starre wrote:

Thanks for all the help. I wish I could determine the actual fix.  I upgraded the DBISAM to the latest version, recompiled and distributed the software.  On one of the customers that was having the issue, it seemed to correct everything and they are back up and running fine.  Another one came back to me before updating and stated that another W10 update seemed to correct the issue.  So, not exactly sure, but happy nonetheless.  I believe it was the temporary file location issue, as the lock file was fine being built in the data folder of the pgm, but it appears a couple of temporary files were also being created and those were not specified as to where they were to be created, so I am going to assume that the upgrade of db solved this issue.

Thanks again for the help, will log this on in the brain for future reference.
Chris
-----------------------

Chris,

Whenever I encounter this error I find it is because I have the table pre-marked as Read Only and don't notice it and then try to do a Write operation to it.

FWIW.

Jerry