FileCopy Problem

[Vlad]

I am having problems with FileCopy as I keep getting a Permission
denied - error 70.

According to the MS Help it states that this error occurs when "You
tried to write to a file that another process locked".

Does this actually also apply to the file you are copying FROM. I.e.
does the source file need to be closed. I am finding that when I try
to copy from an open Access database I can't.

1) Is this correct?
2) Any suggestions for a workaround? - Using API calls I guess.

TIA

Vlad

 

[Marshall Barton]

I am having problems with FileCopy as I keep getting a Permission
denied - error 70.

According to the MS Help it states that this error occurs when "You
tried to write to a file that another process locked".

Does this actually also apply to the file you are copying FROM. I.e.
does the source file need to be closed. I am finding that when I try
to copy from an open Access database I can't.

1) Is this correct?
2) Any suggestions for a workaround? - Using API calls I guess.

Yes, that is correct. FileCopy is careful about copying an
open file because you have no idea what state the file is in
while it is open. This is especially true for database
files where data is being added, modified and deleted
asynchronously. I.e. The copy of the database may very
well be useless.

The obvious workaround is to close the file before
attempting to copy it. Generally, making a backup should be
part of a regular administrative procedure that includes
verifying that the copy is valid so you shouldn't even try
to do it from within the database.

 

[Andibevan]

Yes, that is correct. FileCopy is careful about copying an
open file because you have no idea what state the file is in
while it is open. This is especially true for database
files where data is being added, modified and deleted
asynchronously. I.e. The copy of the database may very
well be useless.

The obvious workaround is to close the file before
attempting to copy it. Generally, making a backup should be
part of a regular administrative procedure that includes
verifying that the copy is valid so you shouldn't even try
to do it from within the database.

Thanks for pointing that out - The next flippant question is obviously "Why
not actually put that in the help file" but I suppose that would be no fun
would it :-?

Andi

 

[Andibevan]

Yes, that is correct. FileCopy is careful about copying an
open file because you have no idea what state the file is in
while it is open. This is especially true for database
files where data is being added, modified and deleted
asynchronously. I.e. The copy of the database may very
well be useless.

The obvious workaround is to close the file before
attempting to copy it. Generally, making a backup should be
part of a regular administrative procedure that includes
verifying that the copy is valid so you shouldn't even try
to do it from within the database.

Thanks for pointing that out - The next flippant question is obviously "Why
not actually put that in the help file" but I suppose that would be no fun
would it :-?

 

[Marshall Barton]

Thanks for pointing that out - The next flippant question is obviously "Why
not actually put that in the help file" but I suppose that would be no fun
would it :-?

Can't disagree with that, but, to introduce a little reality
in the question, Help does clearly state the restriction.
Besides, it takes a half dozen people over a year to create
the Help system as it is. If they tried to deal with all
the standard computing issues that people might not be
familiar with, they may never finish it.