>
>Okay - it's not just VFP - he has had to do it with VB.NET, C#, C++ and other apps he administrates. He has not installed SP2. He also suggested it's a common task in enterprise administration with XP desktops.
>
>The "desktop" tools - explorer for setting folder permissions and regedit - for setting registry permissions - are not enough.
>
>I remember watching him do this and was surprised how many times a request from a process was unable to locate an entry - even though it was there and permission were correct - eventually the process got connected - but it was nothing like I expected - i thought the registry index was so tight that any request was answered at first "asking". But that is not the case - and it is sobering to learn just how imprecise the XP registry engine really is.
>
>He used a downloaded Regmon and filemon. He used them together. He suggested opening a regmon session and then starting the VFP program. He said that the conflicts will immediately pop up. He used the filters to exclude requests not related to my application. And then - one by one - set the registry permissions and file permission my application required. He used both filemon and regmon to do this. He had to do it on every desktop for this that or the other. And it just wasn't my VFP clients - so it's not a VFP issue - it'a an XP issue.
>
>You may be in luck - ask your system administrator if he/she has used regimon and filemon to resolve folder and registry issues.
>
>If you know an independent NE who might have this kind of experience it might be helpful to "use" him.
>
>If you do it yourself - we all expect to see a white-paper in the KB. I have not checked foxcite or searched Scirus for a resolution paper - but some VFP guy or gal who also wears an "XP" hat may have reduced to a level for our humble consideration.
>
>The "new" permissions persist - you can uninstall - and reinstall - and won't have to re-set the permissions. I think that subsequent installs of other VFP apps of mine they use did not require a "permissions" administration - once it's done - it's done.
>
>There were other issues too, though VFP 6 may be outside them. I used to "DEFINE CLASS" for ocx in PRGs - worked great with VFP 6. With later versions - and the msdn has a paper - a VCX for OCX is required. The "oleClass" name has to be presented to the "BUILD PROJECT" as a property in a vcx container.
>
>Why can't MS give us a little utility or service for this that would do it automatically for our installs. VB and C# and C++ experience the same issues.
>
>I wish I could tell you more - I knew everything with DOS2.1 and 8086 - now I know nuthin - nuthin!

Thank you very much for the detailed explanation. I will relate it to the customer SA. You see they are overseas (in Aruba) and they use an outside SA person/company. Unfortunately I can't be there to help them (and I am not really much help when it comes to administrative issues). And I can't "make" them do much testing, they don't work for me. And my customer is just one of their many customers. So, it is Catch 22.

Again, thank you for your help.