John,

>>I have told you many times... we do heavy data munging in our vfp app and fox is great at that; however, we are testing the same type of munging on .net and have yet to see a real difference in speed of efficiency.

OK. And as I responded, I *have* seen a difference. As may you, depending on what exactly you need to do. To what precisely are you objecting here?

>>I can tell you we haven't hit the processes with 100k's of records yet, but the preliminary tests look good.

How many instances of this will you have? If it is for a daily report, i.e. one instance, it may not matter how you do it, though you might want to schedule it away from routine batch processing ;-) Actually, doing it at the server may well reduce network load and multiply the benefit, if you don't need those records at the client for some other reason. But if you are doing transactions that require this every time, or if you need the processed records at the client for whatever reason, IMHO you'll start wanting to do some of it at the client ;-)

>>Instead of thinking like a vfp programmer using .net, you must think like a .net programmer using .net.

Gee, thanks for that! But "As I have told *you* many times" ;-) we *did* try using the backend and middle tiers like good corporate dotNET citizens. Doing it at the server caused a visible performance hit once you had more than one instance going at once. Middle tier, memory residency killed us.

All I'm saying is that it would be a shame to "not know what we've got till it's gone". That was a risk when people were advocating a wholesale migration to dotNET. It seems unlikely now that MS has committed to make autospanning a priority in dotNET. I can't wait!