On one hand, I can do this:

SQLEXEC(1, '{call spTest(?@lnRetval1, ?@lnRetval2)}')


Or, I can do this

oCmd = Createobject("adodb.command")
With oCmd
.Activeconnection = oConnection
.CommandType = 4
.CommandText = "sptest"
.Execute
EndWith

?oCmd.Parameters("@lnRetVal1").Value
?oCmd.Parameters("@lnRetVal2").Value

No question I could take the first part of the code and encapsulate that in some sort of factory class. That is what we do with DataClas COM. Theorhetically, I could shrink it down like this:


oCmd - oADO.ExecuteADOCOmmand("sptest",oConnection)
?oCmd.Parameters("@lnRetVal1").Value
?oCmd.Parameters("@lnRetVal2").Value

WIth SQLExec, it is a VFP only mechanism. WIth ADO, I can place that in my toolbox and use it in VB, ASP, C#, etc.... With ADO, I get the benefit of working with objects. I can pass the command object around, I can iterate through collections.

If you evaluate approaches purely on lines of code, I would submit that is a very short-sighted way of looking at things. With OO, an argument predicated on number of lines of code is easily dismantled. However, in a pragmatic way, using something like SQLExec, everytime I add a new output parameter to the SP, that line of code has to change. If I am using an ADO Command Object, the code that manages the command object does not have to change. The UI or some other code may have to change. So the issue is not whether something has to change. The issue is both minimizing what has to change and further, making sure the right things are getting changed.

That said, I will take my chances with ADO. To directly answer your questions - SQLExec is not better..... Unless of course you don't want to deal with MDAC. In that case, you have to stick with SQLExec. But that forces you to stay in VFP. Any approach that forces me to stay in a specific environment - on that is not portable is not a better approach IMO...


< JVP >