[AccessD] FS object

John W. Colby jwcolby at colbyconsulting.com
Wed May 5 07:41:03 CDT 2004


Bobby,

This brings up a good point.  If your application requires scanning
thousands of files and cataloging them, or something of this magnitude, then
worrying about sub milli-second differences in speed / operation pays off
and is worth the programming effort to optimize.  OTOH, 99.9% of Access
users don't do anything remotely resembling something this massive.  If your
need is simpler - creating directories, copying files etc., then the FSO is
a wonderful tool, completely documented, very flexible, intellisense while
you are programming it etc.

It is annoying to get a "I hate the FSO" with nothing to back up why other
than "VBA is capable of everything I need and is faster".  Yea, so what!
What are YOUR needs and HOW MUCH FASTER.  And what in the world does this
have to do with me?  I am supposed to ignore a very versatile tool because
"VBA meets YOUR needs and is faster (How much faster?  For what purpose?).

My friend Jurgen worked for an organization where the Net Admins ran their
organization like a concentration camp, locking the place up like they were
guarding nuclear weapons (our military should have their security!).  He
worked on slow computers where every processor cycle counted, over dial in
connections.  All of which means absolutely squat to me.  I have NEVER
worked in a place like that (and I've been doing this for a decade now!) but
I am supposed to waste my time NOT using a perfectly good tool because
Jurgen HATES it?

I don't think so!

If and when I run into the idiot net admin I will develop the tools
specifically for that customer to get around the idiot, and charge them for
their requirements as I'm sure anyone else would do.  In the meantime I have
no intention of charging my sane clients to develop stuff they don't need
developed.

For anyone who has ever bothered to look, the File System Object is to the
file system what the Outlook object is to Email, what the Excel object is to
spreadsheets, what the word object is to documents.  These are all just
programming models for writing the application in the least amount of time,
using prewritten objects to do one piece of the task without ground up
programming.  To ignore such tools without specific (valid) reasons applied
to the specific task you are working on is ludicrous.

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Bobby Heid
Sent: Wednesday, May 05, 2004 7:54 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] FS object


I found quite the opposite using the dir function in VB6.  The API (not the
FSO) was orders of magnitudes faster in getting all of the file names and
information about the files off of a large hard drive.

Bobby

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jürgen Welz
Sent: Tuesday, May 04, 2004 10:34 PM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] FS object


I find the scripting runtime is not enabled in many environments.  Hence no
FSO.  VB(A) is incredibly fast in working with the file system.  File size,
date modified and file/folder names are immediately available from the Dir
function.  I ran a test comparing the API dir performance with VBA Dir and
the VBA was faster.  The api could retrieve file creation time and
additional attributes but at a cost of performance.  You can create
directories in less time than it takes to load the FSO.

I have never had to provide any file system functionality that wasn't
already built into VBA.  When the job calls for a scalpel there is no need
to get out a chain saw or a back hoe.  It's also like a comparison between a

public shared plastic spoon vs your own private silverware.

Ciao
Jürgen Welz
Edmonton, Alberta
jwelz at hotmail.com





>From: "John W. Colby" <jwcolby at colbyconsulting.com>
>
> >Have I said before I hate the FS object...
>
>No doubt.
>
>Not sure exactly why.  It is just an object model that allows
>manipulation of the file system.  Why not hate DAO?  Why not hate the
>Excel object model? Why not hate ...
>
>Never mind.
>
>It's just a tool.
>
>John W. Colby
>www.ColbyConsulting.com

_________________________________________________________________
Add photos to your messages with MSN Premium. Get 2 months FREE*
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=htt
p://hotmail.com/enca&HL=Market_MSNIS_Taglines

--
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com






More information about the AccessD mailing list