DWUTKA at marlow.com
DWUTKA at marlow.com
Thu May 6 14:01:12 CDT 2004
Um ya, CDO requires a mail server, but what do you think Outlook uses to send mail? Magic? LOL. CDO is the core of MAPI. You can use MAPI, but if you know how to use CDO, it's a little more flexible. I sent Francisco a VB program, off list that displays the file folder sizes of the .pst files you use in Outlook. Does exchange folders too. It all uses CDO. If you want, I'd be more then happy to send that to you offlist. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of John W. Colby Sent: Thursday, May 06, 2004 12:19 PM To: Access Developers discussion and problem solving Subject: RE: [AccessD] FS object OK, I'll bite, what the heck is CDO. I went out and found a bunch of stuff on Google but from what I can find it requires a "mail server". Will this work for my system here at the home office or clients with just a workgroup? You realize that the response you just gave is one of those "annoying" pretty much useless things. If you're going to claim you use some wonderful whizbang widget you could at least provide a link to get started in understanding how in the world I can use your wonderful whizbang widget. 8-( John W. Colby www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of DWUTKA at marlow.com Sent: Wednesday, May 05, 2004 4:15 PM To: accessd at databaseadvisors.com Subject: RE: [AccessD] FS object 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 -- _______________________________________________ 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