"File Access is Denied" error in a network 1

[rlawrence]

Hi,

I have a user running my application in a network setting and getting a "File access is denied" error. The error occurs when opening free standing tables at the beginning of the application. The thing is that the table that frequently (not always) causes the problem is in the middle of a list of tables to be opened. All tables (25 of them) are opened for shared access.

I have several other clients running this application--most without a problem. I have one other client that complains of frequent crashes. I posted a question on this forum about that and received some excellent suggestions.

But this problem seems to fail consistently in the same spot--on the same table. I am strongly suspecting network issues, but this is a fair sized network (120 employees) and the problem seems to be unique to the few users that are using my application. Of course, Foxpro is probably unique in the network.

The data is currently located on a server. I have asked the client's IT person to relocate the data to one of the user's machines to see if the behavior changes.

I could use some help with a troubleshooting plan to narrow the problem down to something specific. Can any of you offer some suggestions?

Thanks in advance,

Ron Lawrence

 

[Mike Lewis]

Ron,

The usual reasons for this error are:

(i) You are trying to open it exclusively, but another user has already opened it (but it sounds like that doesn't apply in your case); or

(ii) You are trying to open it for shared access but another user has opened it exclusively. Is that possible?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[rlawrence]

Hi Mike,

Well, all users are running the same application and all tables are opened for shared access. I am assuming (though I will confirm) that the users is not doing something like running the single-user version of the software on one machine. But even if this were so, the error would occur long before it got to the table in question.

Also, the routine that opens the tables does so by processing through the table names in an array. So, all tables are opened in exactly the same way.

Thanks for the quick response.

Ron

 

[rlawrence]

One other tidbit of information. The IT person told me that their client machines were loaded using a Ghost image. I can't think of any reason why that should cause a problem with the application, but it should insure that all of the client machines are the same.

Ron

 

[Mike Lewis]

Ron,

Access rights is certainly an issue. If the user doesn't have sufficient rights to the file in question, you might well see this error. It would be surprising if that applied to just one file out of 25, but worth checking.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[GriffMG]

It sounds to me like opportunistic file locking getting the better of you.

Briefly, M$ servers don't do file serving very quickly. So, in order to perform as well as (say) Samba or Netware they invented this diabolical system where a workstation asks to open a file in shared mode - but gets it in exclusive, where it can be used faster. If another workstation also needs it later the server is SUPPOSED to ask the first workstation to release the file, and get it in shared mode.
The problem is that the workstation software sometimes can't get the message and so the whole thing goes to pot.

You will need to load some registry entries on the server and workstations to get around this.

Exactly which registry entries are required will depend on the version(s) of Windows you are using.

Try typing 'opportunistic file locking' into google and you will find a number of solutions.

Regards

Griff
Keep [Smile]ing

 

[GriffMG]

http://www.addsuminc.com/index.html?oplockset.html

Have a very good explanation of the problem at the link above - and a cheapo utility that I haven't tried.

Regards

Griff
Keep [Smile]ing

 

[rlawrence]

Griff!

Wow! Does that shed some new light on some old problems! This is not to say that this is the cause of this particular problem, but you've given me some VERY useful information.

Thank you Sooooooooo much!

At the risk of belaboring the point, the other major area of concern is a hardware failure on one of the machines in the network. Has anyone got any thoughts on testing for this? Any handy utilities for testing connectivity for example?

 

[GriffMG]

I have seen the symptom you describe before, on Netware servers. They used (I don't know if they still do) have a 'black hole' problem.

Essentially, in normal operation, if part of a disc was seen by the OS as a bit dodgy Netware would quarantine it and then use what was called a 'hot-fix' to direct that bit of data elsewhere on the drive. This worked really well most of the time - except where the duff bit was in the FAT itself. Netware didn't seem to be able to use the hot-fix for that and then the server would just keep reading the file as if it was infinately long.

This generally only happened on older discs - as they wore out. Is it possible that your clients servers have a similar problem?



Regards

Griff
Keep [Smile]ing

 

[Mike Lewis]

I've never heard of this "oplock" problem before, or the utility that claims to fix it. Ron, as you say, it could explain a lot of problems.

If you learn any more, please let us know.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[GriffMG]

Hi Mike,

I must have banged on about op locks half a dozen times on here - perhaps you lost the will to live!

I only came across the utility today - it seems like a good idea to me, better than importing .reg files.

Martin

Regards

Griff
Keep [Smile]ing

 

[rlawrence]

I've ordered the utility. I'll let you know if it makes a difference.

Some of my clients--particularly those that are networked--have had issues with data corruption of varying types over the years. One issue has been duplicate keys, which I've shared on this forum in the past as well. This happens even though I go to great pains to insure that it won't happen. I've taken further steps to eliminate this problem, but it is clear to me that I have been dealing with something at the operating system level--not something that I have done in the VFP code.

The articles listed on the page that Griff passed on are also VERY helpful. I will certainly let you folks know if I learn anything new about this situation.

Thanks again to all for your help.

Ron