Problem with Set a = fs.CreateTextFile (1 Viewer)

[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.

 

[Pat Hartman]

"Permission denied" sure sounds like a security issue. Are you sure you have permission to create the file in that folder? Try creating the file in a folder you know you can write to.

 

[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).

 

[Pat Hartman]

More than 24 hours ago, I suggested that the OP try to create a file in a different folder to see if this is a security issue that applies to just that folder since clearly, it is a security issue. We just don't know the extent of the restrictions.

If the OP ever tries my suggestion and reports back, we'll all know.

 

[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.

 

[Pat Hartman]

I can write to any folder on my hard drive except some Windows protected folder. When you are working in an office, you may run into more restrictive security.

So, we have determined this is a security issue.

@Batocanin Is this your PERSONAL computer or one that belongs to and was set up by your employer? Did you try writing to a folder OTHER than the root folder on your C: drive? Or did you just try writing to the root folder on different drives? As others have mentioned, the root folder may be set up with different permissions than subordinate folders. This was a problem back in the DOS days because there was a limitation on the number of files that could be stored in the root folder and if you wasted the space by using the space for files, you invariable created a problem. So, you needed to use the root to hold FOLDER names and then you could store as many files as you wanted in any other folder but Windows doesn't have the same constraint or the root is large enough that people rarely exceed the number of names it can hold or maybe they're just smarter and don't put files directly into the root directory.