Dir function throws error when no access to file

[KaleeyJ]

I have an Access/Jet app with a ton of VBA, and a few particular funcitons are giving me trouble.

We have a part of this program where we can link a file name (with the full path) to an order. This works well most of the time. This gives us a record of what datafiles were used.

Recently, we had another department start using the Link function to link /their/ files on the network (original documents, design files, that sort of thing). The problem is that not everyone has at least read access to these files - and when the form loads and checks the file names, if the current user does not have access to that file, Dir throws a "Bad file name or number" error.

Does anyone have any solution to this aside from giving everyone read access to everything? The builtin Access non-help is about as helpful as usual - any suggestions?

~KJ

[ADezii]

I have an Access/Jet app with a ton of VBA, and a few particular funcitons are giving me trouble.

We have a part of this program where we can link a file name (with the full path) to an order. This works well most of the time. This gives us a record of what datafiles were used.

Recently, we had another department start using the Link function to link /their/ files on the network (original documents, design files, that sort of thing). The problem is that not everyone has at least read access to these files - and when the form loads and checks the file names, if the current user does not have access to that file, Dir throws a "Bad file name or number" error.

Does anyone have any solution to this aside from giving everyone read access to everything? The builtin Access non-help is about as helpful as usual - any suggestions?

~KJ

What exactly are you looking for?

1. A more descriptive Error Message?
2. Resume program execution if the specific Error occurs?
3. Stop Program execution?
4. Aside from granting Read Access, I do believe you are sort of handcuffed.

[KaleeyJ]

What exactly are you looking for?

1. A more descriptive Error Message?
2. Resume program execution if the specific Error occurs?
3. Stop Program execution?
4. Aside from granting Read Access, I do believe you are sort of handcuffed.

I suppose that if we have to do either read access or continue running, security dictates that we continue running, suppressing error messages unless they try to open the file.

I was hoping someone had done a work around - like ghosting as a read-only user or something similar. The problem is that keeping the error messages is useful if the file doesn't actually exist - I was hoping to only suppress them if the file was not accessible. Which means that it might as well not exist.

Groan.
I hate "fixing" things by screwing with the error handling. It really makes me nervous.

Anyone else?
~KJ

[ADezii]

I suppose that if we have to do either read access or continue running, security dictates that we continue running, suppressing error messages unless they try to open the file.

I was hoping someone had done a work around - like ghosting as a read-only user or something similar. The problem is that keeping the error messages is useful if the file doesn't actually exist - I was hoping to only suppress them if the file was not accessible. Which means that it might as well not exist.

Groan.
I hate "fixing" things by screwing with the error handling. It really makes me nervous.

Anyone else?
~KJ

If a File does not exist, or it does exist and the Path to it is incorrect, the Dir() Function will return a Zero Length String. If the File is not accessible, Error Number 52 will be generated - Bad file name or number. Why can't you simply set an Error Trap for Error Number 52, then suppress any Error Message. If the File doesn't exist, simply check for a return value from Dir() of a Zero Length String, then display an Error Message. Will this work in your current situation?

[KaleeyJ]

Ahhhh... I thought the error was generated anytime the file couldn't be accessed through the given path, whether it be due to permissions or bad typing. Perhaps I need to check our code again - I apparently was mistaken.

Yes, that helps considerably.

Thank you!
~KJ