[AccessD] FS object

Great piece of writing.  A bit different from "did I say I hate the FSO".
It doesn't explain why you would hate the FSO, but it does explain why you
would not use it in this situation.

John W. Colby
www.ColbyConsulting.com

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


I used file system functionality to generate lists of files on laptop and
server.  Sine the application named files with a standard name and an
incrementing suffix in the name and because one of the applications changed
the file last modified stamp even if only opened for viewing and because the
data was stored in fields such that you could not tell whether a file had
been modified by any combination of time stamp and size, the synchronization
routine was primarily based on file name.  A difference in size was a
guarantee of a different file version between laptop and server.  The system
generated the names of over 4 gigabytes of active files on the server and 4
gigabytes of files on the laptop everytime a user shut down, compared the
lists and copied files missing on one or the other to where it was missing.
This happened on demand and automatically everytime a laptop user shut down
the application.

Needless to say I searched for the quickest solution since I had 6 laptop
users who would be working out of the office and back daily, and often
several times a day.  The FSO was never an option because the scripting
runtime was not available and a version of the code I developed from the api
examples in the VBA companion book to the 97 Developer's Handbook ran about
20% slower.

That system generated the file structure and synchronized all template files
and determined the path of every file of every type required by emulating
the database structure in the file system.  A table/field name path beneath
the location of the BE was determined and a hierarchical interpretation of
the relational database generated the structure in the file system and
automatically saved files in locations generated on the fly.  In addition,
file names were never stored in a table but always used to populate lists
generated on the fly using the Dir function.  I also provided sorting by
name/date/size by clicking on a 'header' and the system continues to work
very well.  Because this was such a pervasive part of the application, I
invested considerable research and effort into fine tuning it and I am very
surprised to hear anyone say that the api versions are faster.

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





>From: "Bobby Heid" <bheid at appdevgrp.com>
>
>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
>

_________________________________________________________________
MSN Premium helps eliminate e-mail viruses. 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