Re: Problem with FreeTDS validating SQL commands (actually a ct_cancel() error)

James,

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)) ;

to:
	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  
properly.
So the final line of the case statement should be

case _CS_COMMAND_SENT:
.
.
.
cmd->cancel_state = _CS_CANCEL_PENDING;

or 	

conn_cmd->cancel_state = _CS_CANCEL_PENDING;

(depending on context)


Stephane
Atimi Software Inc.
[email protected]





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
> [email protected]
> http://lists.ibiblio.org/mailman/listinfo/freetds
>