>>My instinct is to want to have a DCOM-based configuration owner/manager; sessions are established locally, the DCOM server is contacted, the user is authenticated and the server hands the station information on the hows and wheres of the data to use. It can also be used to verify the app components are current - it's the wise old owl that knows about the state of the system software and data.
>>
>>This mechanism does several things. First, it's a way of providing a central control mechanism. It actively manages the configuration - the user does not have a direct line to the configuration detail, reducing the risk of the enduser tromping on the info with Word. The security context of the configuration detail can be different than the general data file permissions.
>>
>>This is theory, not practice. Your turn. Bitches/gripes/complaints?
>
>My, my. This seems a little like telephone tag.
>
>Although the DCOM suggestion seems extreme, it IS a solution to the problem. MicroSoft has provided wonderful solutions for 2/3rds of the typical environment - user settings and machine settings in the registry. Now, if they could only map this wonderful solution to the other third - I'd LOVE to see a network registry!!! Perhaps this is analogous to Novells NDS - actually - NDS is exactly that!!!
>
>Ooops - make that 2/4ths - I completely forgot about the extranet! Now what?!?!?

MS didn't miss a beat - 4 little letters - ADSI. The Active Directory provides exactly the set of services you want, even to the point of integrating and virtualizing gag NDS...and it's a COM thang! That means we can use it inside and outside of VFP.

In my ever-continuing proselytization for Wrox Press books, there's a very dense but detailed book that shows how ADSI works in conjunction with ASP, called ADSI ASP Programmer's Reference (strange how all their books have a common, descriptive name.) There's a remarkable amount of stuff in the book. I didn't get it all in the first read. Or the first 5 reads. The instant it clicked, the capabilities knocked my socks off. It's well worth the investment in time and effort to learn enough about ASP to really understand the examples in the book. A little familiarity with VBScript, a little XML, and a little basic grounding in what ASP is will help make the book an easier read. What you don't know you can work around, but it's that much more effort you need to put into understanding and leveraging the book from the VFP perspective.

ADSI doesn't need ASP to work, BTW - we can use ADSI automation objects right in VFP, with a little effort and care. You do have to take the positive measure of adding ADSI to the network environment, and that may well be the toughest sell for people who don't feel a need to move to the Win2K model of MS Networking, or are entirely happy with NDS and don't want or feel a neeed for ADSI along side or on top. You can add ADSI to the environment without the Win2K model of networking, but there are things in ADSI that you can't leverage directly in the NT domain environment.

Um, I think it's safe to say TAG! You're it!