Hi John!

I know when it comes to ADO, you're the man and I agree with your statements... for the most part. When you discuss relying on stored procedures to give you your recordsets, that works fine for an application in which you have complete control over the database and its design and you can count on those stored procedures. And though it may offer better speed and flexibilty in changing the result set, I don't think it offers enough in regards to changing data sources completely. Mostly, either because of little syntax differences or simply not being able to count on the fact that a stored procedure like that exists.

Personally, I prefer to let the database handle the insert, updates, and deletes itself. However, as a general rule, I don't like making any assumptions when it's possible to avoid them. It just results in less headaches for me in the long run.

Now then, I didn't mean to imply that someone should hardcode something into the commandtext property of the command object. That would defeat the purpose of using the parameter objects. If you use those with the command object, you shouldn't have to know anything about the actual syntax, except maybe wilcards and such. However, those can easily be stored somewhere and retrieved depending on the connection object or some other variable that tells you what back-end you're dealing with.

Course, that's just my opinion. If what I've just said is wrong, then please, by all means, let me know the flaw(s) in my logic here.

><<
>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.