Problem with Set a = fs.CreateTextFile

[Batocanin]

Way this code dont work in accesds 2016

Private Sub C71_Click()
Set fs = CreateObject("Scripting.FileSystemObject")
Set a = fs.CreateTextFile("c:\testfile.txt", True)
a.WriteLine ("This is a test.")
a.Close
End Sub

 

[theDBguy]

Hi. Welcome to AWF!

Are you getting any error messages?

 

[jdraw]

Your code with a little adjusting worked for me. Using a sub, not a form/button.

Sub TMay30()
    Dim fs As Object, a As Object
    Set fs = CreateObject("Scripting.FileSystemObject")
    Set a = fs.CreateTextFile("c:\users\jp\documents\testfile.txt", True)
    a.WriteLine ("This is a test.")
    a.Close
End Sub

 

[Batocanin]

Hi. Welcome to AWF!

Are you getting any error messages?

Run-time error '70':
Permission denied

 

[theDBguy]

Run-time error '70':
Permission denied

Just as a test, try creating a folder in the root directory (e.g. C:\Test\) and update your code to create the text file there to see if it makes any difference.

 

[The_Doc_Man]

Way this code dont work in accesds 2016

Private Sub C71_Click()
Set fs = CreateObject("Scripting.FileSystemObject")
Set a = fs.CreateTextFile("c:\testfile.txt", True)
a.WriteLine ("This is a test.")
a.Close
End Sub

Syntactically and semantically, there is nothing wrong in that code. It should run in any event routine since technically, all events and any functions or subroutine they call are of equal CPU priority and are part of the same process and in the same memory space, therefore of indistinguishable execution context.

However, it is quite common in an office environment, particularly if the office has an activist IT department that uses group policy files, to block WRITE access to the system disk's root folder - which is exactly where you are writing. The error message suggests this might in fact be the case. While it IS possible for you to set the root folder of the C: drive to be READ only, it is uncommon on a personal standalone machine. Which is why I brought up the idea of an active IT department.

Factors that could change this include whether Access is running as you, as administrator, or as some other user; and whether your IT department is active or more passive in the way it manages your environment.

 

[sonic8]

it IS possible for you to set the root folder of the C: drive to be READ only, it is uncommon on a personal standalone machine.

It's not uncommon at all. It is the default for any Windows installation since Windows 7 or even earlier.

 

[The_Doc_Man]

But @sonic8, on a personal machine you are also more likely to be running as an administrator and thus can create files there anyway.

 

[sonic8]

But @sonic8, on a personal machine you are also more likely to be running as an administrator and thus can create files there anyway.

More likely, yes. But, not being administrator on your personal computer is also the default after a new Windows installation. Not by restricting your account permissions but by limiting the capacity of the account with UAC (User Account Control).

 

[Batocanin]

Yes, it must be something with administrator rights.
There is a problem with disk C: or D: but if I try to create a file on any other disk E: or F: it works.

 

[ADIGA88]

Yes, it must be something with administrator rights.
There is a problem with disk C: or D: but if I try to create a file on any other disk E: or F: it works.

Indeed modern versions of windows almost you can't write outside your user file without administrative privileges, so try to use your user folder.
you can run access as administrator but this is not recommended.