CreateObject("Scripting.FileSystemObject") ?

[MPM1100]

This question was also posted in Programming....

I am having to go back to an Access 97 format. In the current project we use
the FileSystemObject to reference, parse, and do other essential file
manipulations.

When trying to create the object in 97, an error occurs, stating something
like "ActiveX component can't create object." Tried to set the only two
script references, Microsoft Script Control 1.0 and Microsoft Scriptlet, but
still get the error. Is this action even possible in 97?

Thanks in advance...
MPM

 

[Douglas J. Steele]

If you feel you need to post to more than one group (HINT: it's seldom
necessary), please have the courtesy to cross-post (send the one message to
all groups at once), rather than multi-post (send individual messages to
each group). In this way, all responses to your post will be available
together, regardless of what group the responder was in, and the rest of us
won't have to read your post multiple times. (It also uses fewer server
resources)

If you're using Microsoft's web interface to post, you should see an
"Advanced Options" link at the bottom of the page. You can type the names of
the various groups into the Newsgroup box, separating each newsgroup name
with a semicolon.

Note that it's generally consider to be A Bad Thing to cross-post to more
than about 2 or 3 newsgroups.

 

[Norman Yuan]

When saying "Go back to Access97" do you mean you get the error on the same
computer where you run the later version of Access (200?), or it runs OK on
comupters with Access200x, but not on others with Access97?

Since you mentioned FileSystemObject, I'd bet it is not Access problem, it
is OS problem, since the Scripting Engine (where FileSystemObject is from)
comes in different versions with different OS.

I am not sure what file operation your app does, but you should alway avoid
to use "Scripting.FileSystem" in VBA code. There is nothing you can do with
FileSystem object which you cannot with VBA built-in file handling
functions.

Using FileSystem object, you add unneccesary dependency to an external code,
which could be binary-incompatible, not to mention some strict network
policy could disable it (Scripting Engine)...So, not using it is always the
first option.

If you really have to use it, you might want to make it work with oldest OS
and compile the code. You may also want to try to remove the reference from
the code and use late-binding instead, and then bet on your luck that works
on different OS with possible different version of Scripting Engine.

 

[MPM1100]

Norman,

You are absolutely right about the OS. I figured it out earlier today...
Unfortunately the entire reason the app is needed to run on 97 is that the
hardware and software are out of date. But may I say "Hat's off to you" for
the being the first to figure that out here. You also provided a very lucid
and well thought out response. I do appreciate your consideration and time.
Thanks much!

MPM

 

[aaron.kempf]

Norman;

I'm not entirely positive that I agree with these statements
-----------------------------------------
I am not sure what file operation your app does, but you should alway
avoid
to use "Scripting.FileSystem" in VBA code. There is nothing you can do
with
FileSystem object which you cannot with VBA built-in file handling
functions.


Using FileSystem object, you add unneccesary dependency to an external
code,
which could be binary-incompatible, not to mention some strict
network
policy could disable it (Scripting Engine)...So, not using it is
always the
first option.


----------------------------------------

The FSO / Windows Script Host is on all operating systems released in
the past 15 years.. right? I mean it came with IE 4 on Windows 95
right?

What can _I_ do with FSO that I can't do with files and folders?

How about enumerating files and folders and doing it recursively?
I just really honestly-- have no idea how you're proposing to do that
without FSO.

Thanks

-Aaron

 

[aaron.kempf]

I _DO_ think that sometimes you can use different names for the _NAME_
of this company.

I believe that once upon a time; I've seen this also referred to as
IWshRuntime.FileSystemObject instead of
'Scripting.FileSystemObjects'--

I get kinda confused on the intracacies of using one name over the
other-- I just merely set a reference to it and use the Library.

-Aaron

 

[aaron.kempf]

Again; I don't think that you should be using a CONTROL to do this.

I think that you should be using a LIBRARY.

It is called 'Windows Scripting Host' under libraries; not the ActiveX
controls that you're referring to.

Thanks

-Aaron