Bill,

There could be a setting in Sybase to start this working, but I don't know them. Short story: Just use MS SQL Server<g>. It works better than Sybase in other ways as well.

Here is how I get around it now:

Build a SQL statement that declares a variable, calls the proc with that variable as an output param and then SELECTs the variable in order to produce a result set I can read in VFP.

cSQL=[declare @cNextValue char(12)]+CHR(13)+CHR(10)+;
[exec GetNextID 'KeyFieldName', @cNextValue output]+CHR(13)+CHR(10)+;
[select @cNextValue]

SQLExec(nConnection, cSQL, 'curResults')

cNewKey = curResults.exp

Works like a champ, but I'll probably explore the direct ODBC API calls just to get the experiance.

I sent a little longer version of this message to Aleksey with some examples.

Gary



>Gary -
>there was a way to do this with ms-sql - the examples were with C++ and did not use the standard dsn type stuff. I remember seeing it a few years back on the MSDN whitepaper stuff, and thought it might be a good thing to bind to in VFP, at least for a speed thingie.
>---
>Are you sure that you haven't tweaked the right settings for sybase yet?
>I remember there were some extra things to do to make output parms work in that similar fashion [compared to ms-sql] ..
>
>Let me know how it goes ..
>mondo regards [Bill]
>>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