CreateTextFile permission denied

  • Thread starter janiotjoeawie via AccessMonster.com
  • Start date
J

janiotjoeawie via AccessMonster.com

I've build a script that creates 2 xml files and write them both to the root
of the c drive.
My problem is now that after using this for a while I cannot write one of the
two xml files to the c drive. I get an error permission denied.
The second file is still writen to the same location.
My code is:
Set rs = CurrentDb().OpenRecordset("qry_xml_output")
Set fs = CreateObject("Scripting.FileSystemObject")
Set wf = fs.CreateTextFile("C:\WiCourse.xml", True)
. .
. .
. .
wf.Writeline ("</dataroot>")
wf.Close

The code for the second file is the same except for the file name.
There is no file with the same name at the same location.
Why is the first file not writing to the specified location?
 
C

Clifford Bass

Hi,

Have you tried putting the files in a directory on C: instead of the
root to see if that would make a difference? If that does not help, what
error do you get? And when; at creation, while writing to it, or when
closing?

Clifford Bass
 
J

janiotjoeawie via AccessMonster.com

Hi,

I've tried moving it to an other folder on the c drive. This works fine. The
strange thing is I'm writing 2 files, one is going oke and the other one not.
The error is:
Runtime error '70'
Permission denied
This happens at setting of file
Set wf = fs.CreateTextFile("c:\WiCourse.xml", True)

Jânio

Clifford said:
Hi,

Have you tried putting the files in a directory on C: instead of the
root to see if that would make a difference? If that does not help, what
error do you get? And when; at creation, while writing to it, or when
closing?

Clifford Bass
I've build a script that creates 2 xml files and write them both to the root
of the c drive.
[quoted text clipped - 14 lines]
There is no file with the same name at the same location.
Why is the first file not writing to the specified location?
 
C

Clifford Bass

Hi Jânio,

That error most likely means that the file is (still) open. Either in
your program or in some other program. So if you generate the file and then
open it in some other program in order to see if the generation worked; but
do not close out of the other program, Access would run into trouble creating
it. You could try changing your code to the following, which may help
confirm the issue.

Const cstrFileName As String = "C:\WiCourse.xml"

If fs.FileExists(cstrFileName) Then
fs.DeleteFile cstrFileName
End If
Set wf = fs.CreateTextFile(cstrFileName)

However, that it works in a subdirectory makes me wonder if the problem
is specific to the root directory on C:. Perhaps you do not have full rights
to C:\. Or, perhaps there are too many files in C:\. Also, C:\ is not a
good place to place user files such as data exports, documents and whatnot.

You may want to check you code to see if there is any way for it to
miss closing the file in certain instances. And finally, if you are not
doing error processing and clean up at the end, I would suggest that you do
so, so that you can make sure to close any open files in the event of an
error and also make sure that all of the objects get deleted (i.e. doing Set
fs = Nothing -- technically when the subroutine is exited they are supposed
to be deleted, but that may not happen when an error occurs). If you are not
familiar with doing those things, post back.

Hope this helps,

Clifford Bass
 
J

janiotjoeawie via AccessMonster.com

Clifford,

Thanks for the information. Unfortunatly it doesn't make any change. I've
solved it by moving the files to an other directory. Do it keeps strange to
me that one file is not writing and the other one is.
On the point of error handling you are right. I've to build in more error
handling.

Regards

Clifford said:
Hi Jânio,

That error most likely means that the file is (still) open. Either in
your program or in some other program. So if you generate the file and then
open it in some other program in order to see if the generation worked; but
do not close out of the other program, Access would run into trouble creating
it. You could try changing your code to the following, which may help
confirm the issue.

Const cstrFileName As String = "C:\WiCourse.xml"

If fs.FileExists(cstrFileName) Then
fs.DeleteFile cstrFileName
End If
Set wf = fs.CreateTextFile(cstrFileName)

However, that it works in a subdirectory makes me wonder if the problem
is specific to the root directory on C:. Perhaps you do not have full rights
to C:\. Or, perhaps there are too many files in C:\. Also, C:\ is not a
good place to place user files such as data exports, documents and whatnot.

You may want to check you code to see if there is any way for it to
miss closing the file in certain instances. And finally, if you are not
doing error processing and clean up at the end, I would suggest that you do
so, so that you can make sure to close any open files in the event of an
error and also make sure that all of the objects get deleted (i.e. doing Set
fs = Nothing -- technically when the subroutine is exited they are supposed
to be deleted, but that may not happen when an error occurs). If you are not
familiar with doing those things, post back.

Hope this helps,

Clifford Bass
[quoted text clipped - 7 lines]
 
C

Clifford Bass

Hi,

You are welcome. I do agree that it is strange that one file will work
and the other does not, at least intermittently. However I did just have
another thought. It could be related to your anti-virus program. Maybe it
sees that file and tries to check it, thereby locking it. And maybe there is
some subtle difference in timing between finding the file in the root
directory and finding the file in a subdirectory? You could temporarily turn
off the auto-protection or better, temporarily tell the anti-virus program to
skip the root directory. See if that makes a difference. Just make sure to
turn it back on when done.

Good Luck,

Clifford Bass
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top