Bobby Heid
bheid at appdevgrp.com
Wed May 5 07:56:01 CDT 2004
I have used the FSO before with good results. I think it is kind of like you insinuated, use the proper tool for the job. Bobby -----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 8: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