>Wow!
>
>Guess I touched a nerve there. We found a problem, asked for help, got some hints, solved the problem and reported some more info about the problem and solution to help other people who might be in a similar situation.
>

Call it a matter of what I consider unreasonable expectations of support. It's like expecting to get as much mileage out of my old 200ns FPM RAM chips bought for an old AT clone to work in my latest box. It'd be nice, but in reality, I can buy 256MB of 6ns SDRAM for what I paid for 4 16Kbitx1 200ns DIP chips. I moved everything that needed to move platforms to a newer, more up-to-date version of VFP several years ago (prior to Y2K being an issue), and told people who didn't want to move that they should lock down their environments for the apps to guarentee their longevity, and in the event they wanted to leverage new features unsupportable under the old, stable and well-tested environment, they should seriously consider coverting their app to a newer environment, because the cost of backfitting current product to work with legacy apps will often exceed the cost of converting the legacy app to the new platform. I leave it to them to decide when the cost of retrofits exceeds the cost of not converting apps; I have people who still run FPDOS apps because they provide precisely the functionality they need, and that overrides the advantages of GUI, inter-application integration and the ability to play Solitaire or browse their granddaughter's fave Web site when she's up for a visit to Grandma's house.

It's well past the issue of forced necessity to move platforms brought on by Y2K and COM integration, at least for me. I have the luxury of being able to tell clients who insist on running dinosaurs that I don't have the time to spare to figure out what brand of puppy chow works best with an Iguanadon; I have more business that's fairly fresh and close to current technology for a long time to make supporting other people's nightmares for them, so I have relatively little patience when someone calls and says "Help - my FoxPro 1.02 app that worked so well for years won't run on my new Dell, and the guys who sold me the computer, app and support contract have left for Fiji with no forwarding address". Inevitably, these people think it's going to take 5 minutes to fix, cost next to nothing, and "...while I'm at it, could you just add a few new features at no added cost?" They don't want to hear about upgrades, porting, moving everyone who's still running an 8MB Pentium 75 up to an entry-level machine with a warranty, that I can get spare parts for, or, heaven forbid, cost them something appropriate to the couple of hundred hours it'll take to guarentee that it'll work on the next flavor du jour offered by Intel and MS.

It's on the developer's head to make the client aware of the issues at stake; while it's $ in the developer's pocket, in theory, it's the client's entire business that's being bet on trying to cheap out a port while shifting platforms. I'm far more terrified of a subtle error that noone catches for months affecting the accuracy of the business data than I am that I have to pull a flippin' net cable to run the developer version of FPW. If that's all that's needed to address all your compatibility issues, good luck and godspeed to you. I've got the bitemarks on my butt from previous assumptions that I can do a half-way job of conversion not to go swimming in that river again.

I think the only people who can address your issues are the people at MS tech support, and they aren't going to - the odds are that the errors you encounter involve either the net protocols or the client behavior differences between the Win16 and Win32 platforms; WinNT/Win2K and WinXP are far less forgiving of transgressions of the rules than are Win9x derivatives. My only advice is to research what's involved in supporting pe-Win2K environments; there are administrative issues and differences in the behavior of server and domain controllers in the Win2K platform that must be allowed for explicitly by the network administrator when assigning privileges and operating modes that might have an effect.

>You can't please everyone, oh well, thats life I guess. We are getting the whole system converted to VFP, but untill that time we still have a requirement for running FoxPro 2.6 and it seems so do other people, as there is a FoxPro 2.6 Category on here.
>
>Cheers anyway.