On 30 Nov 2007 00:29:46 GMT, "David W. Fenton"
<XX*******@dfenton.com.invalidwrote:
>Chuck Grimsby <c.*******@worldnet.att.net.invalidwrote in
news:db********************************@4ax.com :
>On 28 Nov 2007 00:52:07 GMT, "David W. Fenton"
<XX*******@dfenton.com.invalidwrote:
>>>Chuck Grimsby <c.*******@worldnet.att.net.invalidwrote in
news:u1********************************@4ax.com :
What information are you trying to get at?
There are API calls and functions built into Access that can do
almost everything that you can get via the FileSystem object.
It's quite useful for checking if network shares are available.
There's no accurate way to do that with the built-in Access
commands (other than attempting to write to it, which requires
cleanup).
You can use API calls for that, David. No problem. NetShareEnum,
for example, shows what shares are available.
With late binding of the FSO, what's the downside? It's easy and
fast without needing to have the API code loaded. What am I missing?
Using the FSO loads a bunch of stuff that isn't needed.
The FSO calls those APIs anyways, so there's a layer that's skipped as
well. Granted, that's not all that important anymore in these days of
cheap memory, but I'm "old school" about that. <Grin>
I also remember the days when scripting was routinely blocked by
Network Admins on most computers. That's not so true these days, NAs
and IT Departments have come to trust (and rely on!) scripts to do the
simplest of things, but old habits die hard. And I do still
occasionally run into conditions where scripts aren't allowed. No one
blocks API calls, so....
What's the upside of using the FSO?
Please Post Any Replies To This Message Back To the Newsgroup.
There are "Lurkers" around who can benefit by our exchange!