File Access is denied, but no sign of another table anywhere!

[T17Rax]

Morning all.

I've just come across an instance of a "file access denied" error. Now, I'm no expert at VFP but I know the basics I would hope and thought I'd post this is here as I've searched through the forums and not been able to find anything, and feel it would prove helpful to other VFP users here like me.

Using a windows 8.1 (x64) OS, for some bizarre reason as mentioned will sometimes prevent you from opening a file shared or exclusively.

I tried to write a command to open a table and wouldn't let me. I thought, "I've another program open that's using the dbf". I closed that down, and I still wasn't able to open the file.
I then thought, "Ahh. It needs to be opened exclusively". Nope, still nothing.

So I thought, "Well FoxPro must be locking it up somewhere. I'll close it all and start again, and run it as admin". Again, nothing.

So I sat there and thought to myself "Hang on.. There's been a couple of times lately with server 2012 and windows 8 where two processes of the same thing are running at the same time, but in two instances. I'll just check task manager..."

Hey presto, there she was. Twice! Once as an app and another as a background process. I've no reason for it to be in the background as nothing on my machine is dependant on it.

Good Job windows 8.

 

[Mike Lewis]

You might want to read up on the differences between exclusive and shared use. The VFP Help topic on SET EXCLUSIVE is a good place to start.

The "File access denied" error happens if: (i) you are trying to open a file with exclusive use, and the file is already open (either in another data session in the same program, or another instance of the same program, or another program on the same PC or elsewhere on the network); or (ii) you are trying to open it for shared use, and another program has it open for exclusive use.

In general, you should not open a file exclusively unless you've got a good reason to, for example, if you need to pack or zap it. If you keep EXCLUSIVE set OFF by default, you won't normally hit that particular error.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[craigber]

There is one gotcha in all this that I've never seen documented. The issue is with EXCLUSIVE OFF and then USE theDbf SHARED, what happens is the table is opened shared, but the DBC is opened exclusive.

Craig Berntson
.Net MVP, Author, Tech Presenter

http://blogs.msmvps.com/craigber

 

[GriffMG]

One other possibility, on a M$ Windows server you may THINK you have opened a file in shared mode, but the server may have provided it
in exclusive mode - to make it a tiny bit faster to process (the original idea was to try and be as fast as Novell Netware back in the annuls
of time). This is called opportunistic file locking.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[dbMark]

Has your issue been resolved? I'm pretty sure you're not doing this, but here's another limit. About 10 years ago MS restricted placing your files at the root level of the hard drive. So you can do C:\temp\myTable.dbf but not at C:\.

 

[dbMark]

Mike Lewis: In general, you should not open a file exclusively unless you've got a good reason to, for example, if you need to PACK or ZAP it. If you keep EXCLUSIVE set OFF by default, you won't normally hit that particular error.

Other reasons: (1) REINDEX or (2) to make data access faster in non-shared scenarios.

 

[Dan Freeman]

Hey presto, there she was. Twice! Once as an app and another as a background process. I've no reason for it to be in the background as nothing on my machine is dependant on it.

You might want to put some effort into discovering the cause or it will continue to happen.

One possible cause is you're missing CLEAR EVENTS, so after you close up all of the visible parts of the application you're still actually *in* the application, hence the appearance of a "background" process.

 

[Olaf Doschke]

A very simple reason is file access permissions and another virus scanning, because exclusive really means exclusive, not only from a vfp runtime.

Bye, Olaf.

 

[Mike Lewis]

About 10 years ago MS restricted placing your files at the root level of the hard drive. So you can do C:\temp\myTable.dbf but not at C:\.

Are you sure about that? It's the first I've heard of it.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[GriffMG]

I'm not sure when, but one security feature does work a bit like that - I used to stop two copies of
a app from running on the same machine by holding open a file in the root of c:, but found I had to
move it because most users don't have enough rights in there.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[dbMark]

Yes, what I said about root drive write access was associated with user rights. It is not an issue for someone with Administrator rights.

If you need to see all the processes running on the computer, besides Task Manager you can also use Process Explorer by Mark Russinovich

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

 

[Olaf Doschke]

Actually there is no question here, is there? Vibrantseeker?

You said you found two processes of your EXE?

Do you have any mechanism checking your app already runs?
Was the second process in another user session, perhaps? If you choose to see all users processes you can ad the Session ID to the vsisible columns and then that secondary process might indeed not be background process, it's visible in another users session, eg remotely connected.

Also what dan said, you might have not cleared the process. I doubt this is a windows errorof automacally adding a secondary process.

Bye, Olaf.

 

[JRB-Bldr]

When I used to encounter mysteries like this at one client's office I eventually had to get a 3rd party tool to assist me.
I got WhoHasNT (

http://www.gadgetfactory.com/whohasnt.shtml)

which enabled me to see who (which workstation) had a table open.

With it I identified the user running something that was holding a table open and could then take the appropriate action required.

Obviously if you had two instances of an application running on your own machine, it would tell you about it as well.

If that was occurring often, you might want to consider using a VFP Application Launcher which, among other reasons to use it, would check for an already running instance.
Maybe something like:

faq184-839​

possibly incorporated with:

faq184-4492​

Good Luck,
JRB-Bldr

 

[T17Rax]

I never expected to receive so much feedback on this and I appreciate all your inputs which I'll be looking into.

It was just odd that I, the only user on my machine, with admin rights and all permissions granted for root drives, couldn't open a file because it was in another process somewhere.

I've not resolved anything just yet, I've not spent much time on it recently but it'll be something I'll be looking out for.
It would help to know why I can't access a dbf and how to get around it. Especially when it's an important table to view...

 

[Olaf Doschke]

Well,

you got the appropriate answers already. There can't be any other reason as some other user or process accessing a file exclusive, if you get no shared access.
Take note VFP defaults in its configuration to use exclusive access and that's fine for development, but not for testing multi user behaviour. I switched that off and made it the default, see Tools->Options->Data, upper right checkbox.

Bye, Olaf.

 

[T17Rax]

Take note VFP defaults in it's configuration to use exclusive access and that's fine for development, but not for testing multi user behaviour. I switched that off and made it the default, see tools->options->Data, upper ricght checkbox.

I will do indeed. Thanks Olaf.

 

[JRB-Bldr]

It would help to know why I can't access a dbf

You have already told us the WHY.
Hey presto, there she was. Twice! Once as an app and another as a background process.

Yes, multiple uses of a VFP data table are most often allowed, but it depends on How that table is being used.
Some uses have an implicit EXCLUSIVE involved with them (e.g. REPLACE ALL or INDEX ON), but most do not.

As to how to get around it...
* First you can examine your code to be certain that SET EXCLUSIVE is not set ON.
* Next you can again closely examine your code to eliminate any chance of operations with inherent EXCLUSIVE's executing when you might be running your 2nd instance.
* You can write your own ON ERROR routine to handle when tables are not available to you - test the table, then if not available, take whatever non-crash steps are needed.
* Or you can take steps to ensure that the application can only be run a single time on your workstation - not an absolute resolution if eventually someone else might run the application on another workstation.

Good Luck,
JRB-Bldr

 

[dbMark]

A very simple reason is file access permissions and another virus scanning, because exclusive really means exclusive, not only from a VFP runtime.

This has already been offered as an explanation of that mystery process, but make sure you confirm whether AV is the issue or not. Years ago one AV app was notorious for constantly assessing tables and slowing everything down. If you edit a table, the AV app may see it has changed and waste cycles locking it to examine it. You may need to exclude certain file extensions from antivirus scanning such as DBF, FPT, CDX, etc.

 

[Mike Lewis]

You may need to exclude certain file extensions from antivirus scanning such as DBF, FPT, CDX, etc.

And that might also be a good thing to do for performance reasons.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads