>
Is the goal simply to get back a value from a stored procedure? Then why do you care about passing objects around and iterating collections? As for the 'toolbox' argument, if ADO is already in my toolbox alongside SQLExec, that's not a valid argument.
>

Honestly, I don't know nor do I care about what the ultimate goal is. What I care about is using consistient techniques that are scaleable. If I can, I want ONE way of doing something. The ability to pass objects around and work with collections is something that is important to me. It is my point, it is the point that supports my argument for scaleability and flexibility - and for sure - you are not going to slap it aside. If you want to make your own points and arguments, fine. The issue is in building maximum flexibility and growth capacity in your applications without signficantly increasing their costs. This issue is about simplicity - not having 10 ways to do something, but one way that works not only in almost every situation in VFP - but in other tools as well. How that is not a valid argument is beyond me... FWIW, I think you are arguing with me for the sake of doing so...


>
That is definitely valid, but I would submit that returning more than one output parameter is relatively rare. As for varying number of input parameters, well, that can be managed in code that uses a VFP 'collection' to build the parameter string. IOW, what you did to autoamte parameters with DataClas can be done to similarly manage parameter strings with SQLExec.
>

As somebody who admits that he has not worked with SP's all that much, how can you say that returning more than one value is a rare or common occurance? As you say, the point is valid..

>
Wait a minute- write VFP code that uses ADO, or write VFP code to deal with SQLExec. Arguing that one way forces you to stay in VFP is sort of circular isn't it? I mean if I write my code in VFP to use SQLExec, and need to do the same thing from VB, I just write VB code that uses ADO. I would have to rewrite my VFP code to use VB anyway, what's the difference?
<

I hope you are not taking debate lessons from Mr. Ryan. He is not a very good teacher...< s >. Erik, using SQLExec is a VFP-specific language item. If I have the choice to use a methdology that is not VFP specific and something that is VFP-SPecific without any additional work and without any penalty - I will choose the non-VFP specific approach.

The deal is, I can - for the most part - take VFP code that implements ADO and paste it in VBScript, VB, VBA, etc.. with a few minor alterations. I cannot do the same thing with SQLExec. I HAVE to use SQLExec in VFP. ADO OTOH can be used in VFP, VB, etc, etc...

Now do you see the point...???? < s >..