#10 Sybase 15.0.2 release breaks this module

[Jim Nusbaum]

Sybase, in the 15.0.2 release, has broken this module, at least for simple use. Previous to 15.0.2 Sybase allowed a type mismatch between the type as indicated in the CS_DATAFMT argument to ct_param and the type of a stored procedure parameter if you were passing a NULL value. So for instance say you have a stored proc that takes a char parameter. You want to pass in NULL as the value for that parameter. Previous to 15.0.2 it didn't matter what kind of type you put in the CS_DATAFMT when you added that param with ct_param. In particular this module would set the type to CS_INT if the value passed in as a parameter was None (NULL equivalent). If the value was indicated as NULL the server didn't even look at the type. 15.0.2 changes that. Now the type in the CS_DATAFMT must match or be implicitly convertible to the type of the stored procedure param.

So in the above example where the NULL parameter value for a char parameter would be passed as CS_INT you will get a type mismatch failure from the server.

The workaround to this is a bit problematic. Usually you just pass in a value and the module figures out the type from the value. But None has no value and no type. So you were defaulting to sending it as a CS_INT. Now the user has to construct and provide a DataBuf object as the parameter value and they have to explicitly construct a CS_DATAFMT for that DataBuf if they want to pass a NULL value.

This is an UNDOCUMENTED change in 15.0.2. So just a heads up that when people start upgrading you are going to get flooded with bug reports from pissed off users.

[Derek Harland]

Logged In: YES
user_id=10339
Originator: NO

Related to this ... server side binding of parameters has other negative effects also. Sybase may prove unable to optimise the query properly when the DataBuffer passed has a different type or higher precision than the column. This module of course has no idea what precision a column may be so will pass parameters as a numeric() type. If that happens to be a higher precision than the column then Sybase may optimise the query very poorly (specifically, it seems to ignore relevant indices on the column and resort to table scans) [observed in Sybase 12.5.x]

This kind of bad decision doesn't happen if the constraint was given in text in the sql. In my teams usage of this module we now bind all parameters client side to avoid this issue.