>>>I think I'll drop out here. You're much more qualified than I to address this stuff.
>>
>>Coward!
>
>Ed! I'm shocked! (Said with tongue firmly in-cheek). Seriously, your understanding of this is beyond mine. My reaction would be to get the connections and find a match of the server\volume part. Of course, that maybe half-a**ed, but that's all I know. You've demonstrated a deeper understanding of this issue than I.
>
>Geez, give a guy a compliment and he starts calling you names.:-)

No, you're just must better at explaining the API than I am, and I'm getting lazy in my old age... ;-)

For a single application where everyone used the same UNC to reference the files, the common UNC reference with NetFileEnum() is probably the best solution; this falls apart in a couple of cases - where the file can be opened with different UNCs is one, or where the app can be run locally, neatly avoiding the issue of UNCs entirely, is a second. The API provides a means to do this, but coding it on a one-off basis, especailly using VFP, is probably not the best resource investment I could think of. It'd probably take me longer to code and debug the one function than it would cost to buy a library with that capability and a whole lot more.

It's the same logic behind buying a framework, or SDT, or West Wind; given time and resources, you could write it yourself, but there's little reason to do so if you can get what you want, already working, for less money.