[freetds] Problem with FreeTDS validating SQL commands (actually a ct_cancel() error)

Stephane Magne smagne at atimi.com
Tue May 20 20:43:24 EDT 2008


Thank you for the prompt feedback.

You helped me to stop chasing a red herring and I finally found out  
what was actually going on.

There seems to be a problem in the file ct.c in the function ct_cancel 
(CS_CONNECTION * conn, CS_COMMAND * cmd, CS_INT type);

I managed to debug the issue by changing our original call to  
ct_cancel() from:
	return (ct_cancel (itsConnectPtr,NULL,CS_CANCEL_ALL)) ;

	return (ct_cancel (itsConnectPtr,NULL,CS_CANCEL_ATTN)) ;

I'm connecting to a Sybase server that would normally use the  
SybaseOpenClient.framework (on Mac OS X).

It appears that in the case statement for CS_CANCEL_ALL, there is a  
line of code missing.

In the case of _CS_COMMAND_SENT, the cancel_state isn't being set  
So the final line of the case statement should be

cmd->cancel_state = _CS_CANCEL_PENDING;


conn_cmd->cancel_state = _CS_CANCEL_PENDING;

(depending on context)

Atimi Software Inc.
smagne at atimi.com

On 20-May-08, at 5:13 AM, James K. Lowden wrote:

> Stephane Magne wrote:
>> Please correct me if I'm wrong, but it's my understanding that
>> ct_command() ... will also
>> determine if it is valid SQL syntax or if the Stored Procedure call
>> is valid.
> I don't think you can depend on that.  I just re-read Sybase's  
> description
> of ct_command.  It doesn't imply any interaction with the server,  
> and it
> explicitly says the command text need not even by SQL:
>  "A language command can be in any language, as long as the server to
> which it is directed can understand it. Adpative Server understands
> Transact-SQL, but an Open Server application constructed with Server-
> Library can be written to understand any language."
> FreeTDS never parses SQL.  If you refer to a nonexistent procedure or
> table, you'll hear about it soon enough from the server.
> The ct-lib reference manual gives no reasons for ct_command to return
> CS_FAIL, and I don't know of a canonical list of library error  
> messages.
> That's the documentation story.  The implentation and emulation
> perspective might be more complicated.  Do you get any more  
> feedback from
> Sybase's library besides CS_FAIL?
>> In contrast, the SybaseOpenClient framework will return the CS_FAIL
>> result if the SQL isn't properly formatted.  However, the source
>> isn't readily available to us so we can't compare the two.
> I'm not aware the source is available at all, readily or not.  ;-)
> What you could do, if you want to investigate further, is use  
> tdsdump(8)
> to capture the server interaction, if any, that results from a  
> ct_command
> call.  If there's something there, we could take advantage of it.  If
> there is none, then I have to say the documented and observed behavior
> agree: you can put whatever language text you please into your command
> buffer.  It's not an error insofar as the library is concerned.
> HTH.
> --jkl
> _______________________________________________
> FreeTDS mailing list
> FreeTDS at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds

More information about the FreeTDS mailing list