SNIP

"There are too many things under the covers that cause too many problems."

You have my undivided attention! I have numerous applications where I'm passing a disconnected recordset to the UI, updating it, and returning it to backend via a middle tier. I use stored procedures in many case but not in all. Just how do these "problems" manifest themselves?

Bob


><<
>Anyway, most people simply deal with the connection and recordset objects. However, in theory (I haven't had time to test it yet), if you make proper use of the command and parameter objects, you could theoretically switch between back-ends simply by changing the connection string. (Assuming they're compatible with and have an OLE-DB provider.) Imagine creating "paramterized" recordsets by properly using the command and parameter objects. Since you're basically telling ADO to give you a recordset where this parameter is this value and so on, you don't have to worry about little changes in syntax. Pretty cool concept, huh?
><<
>
>Travis...
>
>As somebody who has written a thing or to on integrating ADO and VFP <bg>, I would like to make a few comments here....
>
>The best use of recordsets is for passing data around and presenting data....period. As a mechanism for updating data, in a word, they suck. There are too many things under the covers that cause too many problems. In reality, whenever you reate an ADO recordset, a Command Object is implicitly created. It is far better to make direct use of the Command Object.
>
>However, making use the command object is not enough. The notion of hardcoded SQL Statements in program code that is used for the CommandText Property is loaded with several issues. First, it is not that secure. Through the use of stored procs, you can have a more granular security model through SQL-Server permissions. Second, anytime you have a schema change, you need to alter your your basic data access program logic. In reality, all that should change is:
>
>- UI
>- Any middle-tier business rules that need to reference the new columns.
>
>The use of the command object, coupled with the use of stored procedures faciliates this ability.
>
>As far as parameterized recordsets, what we are talking about in VFP-speak are parameterized views. Command objects by themselves won't provide the most scaleable solution. A combination of stored procedures and the command object will.