A very revealing post.

The man acknowledges that he has little practical experience in dotNET.

Your response? A series of demands for practical specifics, using carefully selected examples of your own.

Nice.

Well, I think I have more dotNET experience than you, so I'll provide some specifics.

>> Please explain WHY this is kludgy. I want specifics. I've written queries to produce data in a weekly format for, say, a weekly sales bar chart. In a distributed environment, writing a stored proc on the server to prepare the result set (complete with series data) for the graph is a way to minimize client changes if/when the business rules for the graph change. I know this because I've done it.

You have done these things in SP because the thought of doing it locally in your favoured tool was unpalatable. That is a necessity, not a virtue.

VFP, of course, can also use SP. It can also do it locally. It can also do it as a tier. Which is the point. One is not forced to use the database for all munging. One does not have to argue that SP is always best.

Re personal experience: we tried to use SP for something we are working on very hard at the moment. We gave up. It did not scale- or more correctly, multiple users made it impractical. A tiered approach was obviously the way to go. This is a standard business and technical response, as you know very well.

>>Assuming we're talking about Winform datagrids...I can develop a grid where I derive from the standard textbox column class, and override the paint event to call a function that shows a dollar column in red if the value exceeds a certain amount (the equivalent of setdynamicforecolor in VFP). I can load the grid with 5,000 rows immediately. Navigation through the grid, to the naked eye, appears to be roughly the same as Fox.

I could be a smartypants and lecture you about how grids with 5000 records suggest a design flaw- "no human can digest that many records and you should refine your selection."

However, the useful point is that IME winforms are slow, slow, slow, slow- certainly on the machines my customers are likely to use for ther forseeable future. That doesn't worry me too much- when it came out VFP3 also seemed sluggish, expecially with heavily populated tabs. We acknowledged and handled that issue without trying to deny it. Surely we can do the same for Winforms.

>>many developers coming from VB, Delphi, and other tools are able to pick up on .NET and build data-driven apps without difficulty. They're looking at a slighly bigger picture, and aren't getting bogged down in the fact that a particular function is missing and requires 10-20 lines or so to build a functional couterpart.

"slightly bigger picture", you say? surely you mean "not yet exposed to a local data repository". You watch what happens once that becomes available in dotNET. I mean it.

>>I have yet to hear one valid technical argument why doing this type of work in a stored proc is 'rubbish'.

"Rubbish" is not my word. However, there is an obvious intellectual objection to claiming SP as "the way" simply because that is the only way that makes sense in your chosen tool. That would be like arguing that igloos are the best form of housing because it gets real cold in the Arctic and you need to move around. That makes a lot of sense- if you are in the Arctic.