FreeTDS Development Group

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

> From: Castellano, Nicholas [mailto:Nicholas_Castellano AT acml.com]
> Sent: October 9, 2002 3:22 PM
> 
> The line that you quote [...] appears in the documentation
> for INT_CANCEL.  I'm talking about the behavior of INT_CONTINUE,
> particularly in the anomalous case where an error other than 
> SYBETIME was
> sent to the client.  There is no such qualification in the Microsoft
> documentation for INT_CONTINUE.

Ah, I see your point, and I agree.  

Syb: INT_CONTINUE + !SQLETIME == INT_EXIT; abort.
MS:  INT_CONTINUE + !SQLETIME == INT_CANCEL; fail.
me:  INT_CONTINUE + !SQLETIME == INT_EXIT == (Win32) INT_CANCEL; fail.

IOW, I assumed Microsoft meant, "In any other case, this value is considered
an error and is treated as [an INT_EXIT which in Windows we treat as] an
INT_CANCEL."  But that's not what they say.  Perhaps next time I will rtfm.


> But isn't the point of --enble-msdblib to allow you to take 
> code originally
> written on Microsoft platforms with Microsoft dblib, and 
> compile & run that code with FreeTDS?  

Yes.  The question becomes, how would a programmer want a ported Windows
program to behave on a non-Windows platform?  "Return FAIL from the
DB-Library function that caused the error"?  Or print a message and exit?  

Put that way, I'm inclined to agree with you, because the ported code is
expecting to continue and (presumably) has logic for dealing with or
ignoring the returned FAIL.  

Thank you for your patience.  

--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.