>I need to make calls to an ODBC driver directly. I assume after using VFP's SQLConnect() and SQLGetProp() to get a connection or statement handle, I call SQLExecDirect() and possibly related functions to call a stored proc on the back end, bypassing VFP's SQLExec() function.
>
>Can anyone point me to a VFP example? MSDN has the function calls documented, so I can figure out the individual calls, but I didn't see an example of the calls working together.
>
>The reason for doing something the hard way:
>The use of VFP as a major player for my company's application development hangs on this. The problem is that VFP's SQLExec() fails to get a value from an OUTPUT parameter passed to a stored proc in Sybase. Works like a champ using MS SQL Server, but not with Sybase, I want to try directly, in case the VFP "wrapper" is clashing with the Sybase driver.
>
>This works fine using MS SQLServer:
>cOutParam = ''
>SQLExec(nConHand,[exec MySp 'SomeValue', ?@cOutParam])
>? cOutParam && Changed value by the sp
>
>Sybase:
>SQLExec(nConHand,[exec MySp 'SomeValue', ?@cOutParam]) && Fails
>SQLExec(nConHand,[exec MySp 'SomeValue', @cOutParam]) && Fails
>SQLExec(nConHand,[exec MySp 'SomeValue', @cOutParam OUTPUT]) && Fails
>SQLExec(nConHand,[exec MySp 'SomeValue', @cOutParam OUTPUT],'MyCursor')&& Fails
>
>SQLExec(nConHand,[exec MySp 'SomeValue', cOutParam]) && Succeeds, sort of
>
>The last call succeeds, but is worthless since cOutParam was passed by val and is unchanged by the procedure.
>
>
>I know I can have the sp "SELECT cOutParam = new value" at the end of the proc and look at the result set to get a value, but that's unacceptable. OK, perhaps, for new sp's, but unacceptable for the many existing sp's using OUTPUT parameters.
>
>Gary

Hi Gary,

Can you be more specific?
What VFP version are you using?
How exactly SQLEXEC fails?

The repro code that creates procedure on the fly and then tries to call it is the best.

Thanks,
Aleksey.