FreeTDS Development Group

["Castellano, Nicholas" <Nicholas_Castellano AT acml.com>]

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?  If so, I still think we need to provide the
Microsoft-specified behavior here.

The line that you quote, "With the Microsoft® Windows® operating system,
this value ... is treated as an INT_CANCEL." 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.

Cheers,
--nick

-----Original Message-----
From: bounce-freetds-145195 AT franklin.oit.unc.edu
[mailto:bounce-freetds-145195 AT franklin.oit.unc.edu] 
Sent: Wednesday, October 09, 2002 2:51 PM
To: TDS Development Group
Subject: [freetds] RE: How to treat the error handler's return code (w as:
bug found?)


> From: Castellano, Nicholas [mailto:Nicholas_Castellano AT acml.com]
> Sent: October 9, 2002 1:48 PM

Nick, 

I might not have been clear.  :)  

> But let's look at the case where some other message besides
> SYBETIME has
> been sent, but the user's error handler returns INT_CONTINUE anyway.
> 
> We all agree that this is "bad behavior".  But the response
> to this "bad
> behavior" is explicitly documented by both Sybase and 
> Microsoft.  Sybase
> says it will be treated as INT_EXIT, and Microsoft says it 
> will be treated as INT_CANCEL.

They qualify that.  They say, "With the Microsoft® Windows® operating
system, this value ... is treated as an INT_CANCEL."  They don't say what
their library would hypothetically do if it ran on something other than "the
Microsoft® Windows® operating system".  

I think "#ifdef WIN32" means "when compiled for Windows".
I think "--enable-msdblib" means "as defined by Microsoft".  

The situtation we're discussing is an AND case; both things need to be true.
It is possible to use Microsoft's conventions on a unixy OS, and in that
case we should accept the INT_EXIT and exit.  Similarly, if we are following
Sybase's conventions on a Windows platform, we'd exit, because Sybase
doesn't indicate any special Win32 behavior.  Sybase sells client libraries
for Win32, too, after all.  

> Currently, FreeTDS treats it as INT_EXIT.  That is, we follow Sybase's 
> documented behavior, but directly violate Microsoft's documented 
> behavior.

I say we're not violating anything until the Win32 port works.  It's a
distinction between the OS and the vendor.  

I think it's an important distinction to maintain, because many people use
"--enable-msdblib" thinking they need it to connect to Microsoft servers.
Our documentation doesn't say that, but they do it anyway.  When they do, we
shouldn't mistakenly impose Windowsisms on them.  

Better?

--jkl


> I think we need some way for the user to configure FreeTDS to
> provide the
> Microsoft-documented behavior.  I'm suggesting that we use
> "--enable-msdblib" to choose that behavior.
> 
> What's "not right" about that?



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.