[AccessD] FS object

DWUTKA at marlow.com DWUTKA at marlow.com
Wed May 5 15:14:44 CDT 2004


I would have to disagree a bit there John.  I use CDO or persists ASP email
to deal with email.  Outlook can be just plain annoying with security issues
it puts in place, etc.  If I NEED Outlook, then I use it, but I don't use it
if I don't have too.  Same with Excel.  I have LOTS of applications that
'create' excel spreadsheets WITHOUT excel, instead, I use ADO.  Of course I
do have some that do use excel, when I need to actual format stuff, etc.
But if the client just wants an excel import, or an export to excel, I don't
bother to even mess with Excel. I use ADO, it's faster, lighter, and more
interestingly, doesn't require excel to work.  (And believe me, it's
FASTER.....had an excel import into Access, where importing using Excel took
2 mintues a sheet, and ADO took 5 seconds per sheet.).  Why would I want
something that works without excel?  Web applications, where the web server
is handing out excel files.....who wants office installed on a web server?

Same with FSO.  If you are using a lot of FSO features.....well heck, use
FSO.  But if you just need specific functions, why use FSO?  If I want to
know if a file exists, I use Dir.  If I want to read/write a file, I use
Open "..." For Binary Access Read/Write as x.  If I want to delete a file, I
use Kill.  I find that a majority of my projects that need to interact with
the actual file system, only use a few file commands, not the entire
package.

Just to clarify, I'm not saying there's anything wrong with using either
approach.  Just saying that if something is 'robust', it doesn't make it the
better choice in all situations.  

Drew

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


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



-- 
_______________________________________________
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