>Who?? Me ??? nah.. Of course playing with arrays in process memory is a good idea for munging data. Esspecially the munk work because of course, since the data is in arrays, you can't do SQL anymore. And of course, I'll hear you saying that LINQ is going to solve the problem.

>True, you cannot do full-blown SQL syntax in ADO.NET...but there is a subset of commands for filtering, lookups, and establishing relations. And the structure of the data is a collection, not an array. I've been doing data munging for years in ADO.NET - yes, you sometimes have to apply some elbow grease - but I've always been able to accomplish what I needed.

Which tell us what ?
1. .Net is capable of doing it !!
2. You only do very simple forms of data munging.
3. You have no idea what datamunging means to others
5. Your requiring your .NET application to run at least on a dual core processor with 4 gigs of ram.
6. You don't have a high requirement for performance.
7. Any of the above.


We don't need to fool ourselves. We all know that .NET does not stand a change in a datamunging contest against VFP, esspecially in high volume complex cases.

>I haven't metioned LINQ in this entire discussion.

No, indeed, but I know this will be used in a following discussion when we argue about the same topic. I can use this as a reference.

>Inserting and updating records with SP is a PITA and you have to wonder whether you want this on an evolving system, each time table structures change, you'll have to go through dozens of SP to take care of it. Not exactly fun and and efficient use of time if you ask me.

>Since many generate their insert/update/delete stored procs from a schema or data dictionary, all they need to do is run a job when the structure changes. This is really a non-issue.

Ah, you talk only about the simple stuff. What about the calls scattered arround in your source code? How about on the fly reporting ??

>Don't get me wrong. SPs do have use. They are great for securing when you need it, and for performance (pre compiled plan, though that can bite you as well). But to force people to use SP does not prove of much understanding of its application. You simply have to know when one or the other makes more sence in a given situation from a technical POV, and not because some idiot tells you.
>
>I've never said 'force people to use SPs'. In general, they are a good starting point. If there are specific reasons why other approaches are, on balance, going to be better, then fine.

>But these situations are usually the exception rather than the rule....and in some instances, programmers eschew stored procs prematurely, becuase they are not aware of the power of SQL syntax [example, developers use dynamic sql for non-static lookups, because they aren't aware of COALESCE).

I entirely disagree here. They are a bad starting point. Don't use them unless you are forced to. As for coalesce, yep, performance goes out of the window. Coalesce expressions not optimizable as far as I know. In fact using it for this purpose is a kludge. You're working arround the problem rather than doing something about the problem.

And we did not talk about portability of the SP code yet.

Walter,