FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Castellano, Nicholas [mailto:Nicholas_Castellano AT acml.com]
> Sent: October 9, 2002 10:49 AM
>
> So there is a difference in Sybase's specification versus Microsoft's.
> 
> Perhaps the FreeTDS behavior should depend on whether or not
> "--enable-msdblib" is used at configure time.  Does that 
> sound reasonable?

Reasonable but not right. :)  Long treatise follows.  

== Treatment of INT_CONTINUE ==

There's no difference between Sybase's and Microsoft's description of the
response to INT_CONTINUE when INT_CONTINUE is "meaningful".  

Sybase says:

        "Continue to wait for one additional timeout period. At the end of
that period, call the error handler again. This return value is meaningful
only for timeout errors (SYBETIME). In any other case, this value will be
considered an error, and will be treated as an INT_EXIT."

Microsoft says:

        "Continues to wait for one additional time-out period, and then
calls the error handler again. This return value is meaningful only for
time-out errors (SQLETIME). In any other case, this value is considered an
error and is treated as an INT_CANCEL."

Apart from minor changes in wording, these are identical descriptions for
the "meaningful" (SQLETIME) case.  Both agree that a handler should not
return INT_CONTINUE unless the error it's handling is SQLETIME.  Both agree
that a second attempt will be made which, if it too fails, will result in
another SYBETIME.  

They differ in how they respond to INT_CONTINUE when the error is not
SQLETIME.  They agree that that's considered an error (bad handler
behavior), and give it the most severe treatment possible.  Sybase will
treat it as INT_EXIT and Microsoft will treat it as INT_CANCEL.  

== Treatment of INT_EXIT and INT_CANCEL ==

Of INT_EXIT, Sybase says:

        "Print an error message and abort the program. DB-Library will also
return an error indication to the operating system."

Of INT_EXIT, Microsoft says:

        "Prints an error message and exits the application. DB-Library also
returns an error to the operating system.  With the Microsoft® Windows®
operating system, this value is considered an error and is treated as an
INT_CANCEL."

IOW, Sybase distinguishes between INT_EXIT and INT_CANCEL, but Microsoft
doesn't (in Win32, which is what they provide).  

Their descriptions of INT_CANCEL have different wordings (Microsoft's by far
the vaguer), but AFAICT, they agree on the behavior.  

== Conclusion ==

Except for Win32 programs, the vendors' documents agree.  Ergo:

1.  Never return INT_CONTINUE, except for SQLETIME.  
2.  FreeTDS should treat INT_CONTINUE as INT_EXIT, except for SQLETIME.  
3.  For INT_CONTINUE && SQLETIME, FreeTDS should retry.  
4.  FreeTDS should exit if the handler returns INT_EXIT (or #2).  

There are two Microsoft distinctions:

1.  The treatment of INT_EXIT should follow INT_CANCEL in one case only: on
Win32 ports when emulating Microsoft's behavior.  That is, "#ifdef WIN32"
*and* "--enable-msdblib".  

2.  Sybase allows INT_TIMEOUT and Microsoft does not.  If
"--enable-msdblib", INT_TIMEOUT should be treated as any invalid return code
i.e., "If the error handler returns any value besides these three, the
program continues."  Whatever that means.  I guess FreeTDS should ignore
invalid return codes from the handler, and take no action.  

Sorry this is so long winded.  There are a lot of branches.  

--jkl



The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that for certain accounts we do not accept
orders and/or instructions by e-mail, and for those accounts we will not be
responsible for carrying out such orders and/or instructions. Kindly refrain
from sending orders or instructions by e-mail unless you have confirmed that
we accept such communications for your account. Please also note that to
satisfy regulatory requirements we review the outgoing and incoming e-mail
correspondence of staff members serving certain functions.