Sudden Access shutdown

[makyland]

Hi! Some users of my application are experiencing sudden Access shutdown
(message "Access has detected a problem and needs to close. Sorry for the
inconvenients") when the code tries to execute:

Set fs = CreateObject("Scripting.FileSystemObject")
If fs.FileExists(text_name) Then
Set f = fs.OpenTextFile(text_name, 1, 0)
Set f2 = fs.CreateTextFile(mydir & text_name2, True)
While f.atendofstream = False
<Some actions to copy part of one text into the other>
Wend
f2.close
f.close
Set f = Nothing
Set f2 = Nothing
Else
MsgBox ("Sorry, xml file not present in folder " & mydir)
End If

In principle fs was not declared (neither as Scripting.filesystemobject
(early binding) nor as object –late binding-). The code causes no problem in
most of the laptops but in some others it does. We have check the versions of
every referenced library and found no differences (Access 2003, SP2). What
can we do to avoid it? Will it make a change to declare fs as object? I have
read from Doug J Steele that use of filesystemobject should be avoided. Which
is the alternative?

Thank you in advance for your help!!!!

 

[Alex Dybenko]

Hi,
instead of filesystemobject you can use native VBA statements, like open #,
print #, write #, ect

--
Best regards,
___________
Alex Dybenko (MVP)
http://accessblog.net
http://www.PointLtd.com

 

[makyland]

What about creating a file? When you try to use help you get:

"The following code illustrates how to use the CreateTextFile method to
create and open a text file:

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

"

 

[Douglas J. Steele]

Dim intFile As Integer

intFile = FreeFile
Open "c:\testfile.txt" For Output As #intFile
Print #intfile, "This is a test"
Close #intFile

 

[makyland]

Thank you very much for your responses!!!!

Is there any reference to read why to avoid FileSystemObject???? I have used
it from time to time in other parts of the code, and also in other
applications, but would like to avoid other users reporting similar error..
Do you know why the sudden Access shutdown occurs?

 

[Douglas J. Steele]

I haven't seen anything specific, but the reason I avoid it is that FSO
tends to be bloated. If I recall correctly, in all my coding, the only time
I've ever needed to use FSO was to determine the LastModified date for a
folder (for some reason, I couldn't get the API to work)

If you take a look at an article I wrote for Access Advisor comparing using
FSO, VBA and APIs to find files on the hard drive, in finding 5491 files on
my hard drive, the API approach was about 10 times faster than the Dir
function (.191 seconds vs. 1.222 seconds), while the Dir function was about
10 times faster than the FSO approaches (1.222 seconds vs. 10.285 or 10.295
seconds). I don't know about you, but I'd rather use something that's
faster! (see http://my.advisor.com/articles.nsf/aid/16279 for the article)

 

[makyland]

Thank you very much for your answer!!! I always love to learn new things! The
truth is that I don't usually search for files in my Access applications and
that's why I felt a bit unexperienced on what the best option would be.

This application uses "hard-coded" paths created on installation and there
are not "many external files" to access, so everything was very simple. I
wouldn't have ever worried about the filesystemobject until a user reported
Access getting closed at this time, that's why I wanted to learn what is
wrong with it...

I take this chance to let you know that these Discussion Groups are very
helpful for self-learning developers!!!!