Kevin,

As one with practical experience and in depth knowlegde (that most likely exceeds yours) about VFP and SQL (R)DBMSs I think I'm qualified to say something about this subject.

>1) I'm not using stored procedures out of necessity - I'm using them because it's the best fundamental approach. Even those who built applications in VFP still made the provident decision to utilize stored procedures, to take advantage of multi-processors, SQL-92, and building something tool-independent. The FoxPro application that Rod Paddock and John Petersen developed, and their work on the Fox version of DataClas, is based on stored procedures. So it's not just a .NET thing...

Well there are whole tribes who try to avoid SPs for all kind of reasons. I already gave you a few as well as JohnR did. SPs use valuable resources and can cause concurrency problems. Second, from a theoretical point of view a database is designed to store data, not application specific functionality. If you're working on a big database (let say insurance data in an insurance company) where a lot of applications are attached to one database, Application SPs could create a whole administrative mess up here. And of course there are situation where you are not able to even write SPs for that given database. In an awfull lot of cases using SPT (or views) is a much better choice. When you are able to just download the data you need (sound familiar?) and process it on the client (or another tier) you'll have a much more scalable solution up here.


>Running stored procs can take advantage of ASMP...also, work can be preserved even when the development tools change. I think it's a great solution to deliver to a customer.

Ehhh. How is this ever going to be an advantage compared to a multi tier, multi user, multi application environment using SPT as source of getting the data?

>I just spent a day and a half designing a stored procedure to bring back 3 results sets for a critical reporting process. I *could* have done some of the queries in the back-end and further 'munged' the data before passing it off to Crystal...which would mean two code bases to produce the final dataset, and it would have been unnecessary. By doing it all in a stored proc, all the processing prior to the phsyical report generation is now client-independent.

Using SPT to get your data, does not require any coding on the database at all, so you'll have only one code base: the client. You could have created a tier to which crystal hooks in, making the report client independed also. Don't get me wrong, sometimes there might be valid reasons to write SPs. And I'm glad I've got them, though I try to keep their use to a minimum. If a SP takes one second to complete, it means it eats resources (CPU, Memory, R/W Locks, Disk I/O) from other processes that expect inmediate response, slowing that down. Don't forget the concurrency problems that could occur quite easily where actual processing is done in large time consuming SPs, especially with larger numbers of users in the system. Depending on the type of database application, you can set it isolation level to dirty read, easing the pain a bit, but in situations where the level of accuracy of data is of very high importance (e.g transactional financial databases) you probably have to set it to serializable in which writing data munging SPs is a real thread to concurrency and have to watch your back for deadlocks, even when your SP only reads records in stead of writing).

A friend of mine is a ORACLE trouble shooter. You would not believe the trouble he encounters because of the stupidity (or lack of knowledge) of the developer who just expects a database to do its job efficiently and really does not bother if the implementation is well balanced.

There is also another aspect to this as well. A SQL server has a SET oriented DML, sometimes having some record oriented approach as well. But it is not difficult to prove that xBase languages (who by its origin are record oriented) are way better in datamunging record oriented problems. VFP also has a reasonable SET oriented approach as well, so from a technical point of view VFP is better equiped for a lot of data munging tasks.

Bottom line is. That with VFP you have a choice where to do your data munging. On the server, a middle tier, the client. It does not matter. In .NET you don't have a valuable choice.

And I agree with JohnR in that the tribes comming from VB, DELPHI, JAVA, are not familiar with concepts of local data repositories with real database functionality which in VFP is possible for many, many years. Granted many VFP developer don't realize this. Indeed watch out when the day comes that such functionality becomes in .NET.

>If others chose not to use them, fine - but the previous assessment of "rubbish" (granted, not yours) on a technical forum is just one more example of a strong assessment with little or no accounting for it.

See above qualifycation.

>But again, I really feel you missed the earlier point. Just to recap, about a month or so ago, Walter made a claim that the datagrid in .NET is fine for displaying a small amount of data, but would be problematic when loading the grid with thousands of rows. I challenged that statement, and provided an example of loading a grid with thousands of rows, and going further by deriving from the textboxcolumn class and overriding the paint event to develop a functional 'setdynamicforecolor' that seemed as fast as VFP.

I never brought up a the dynamicforecolor argument so I don't know what you're trying to say here. And you'd better deepen yourself into the difference of a datagrid and a VFP grid, because there certainly are differences in performance. Binding a dataset to it is one. Working with it is two. On certain events where you have to deal with the whole dataset. If you don't believe me just look at http://groups.google.nl/groups?hl=nl&lr=&ie=UTF-8&threadm=eIKJzEIdCHA.2060%40tkmsftngp09&rnum=3&prev=/groups%3Fhl%3Dnl%26lr%3D%26ie%3DUTF-8%26q%3Ddatagrid%2Bperformance%26btnG%3DZoeken. I did make a statment about datagrids, and only after you asked for it, so please respond on this link above.

Walter,