FreeTDS Development Group

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

> From: Coleman, Dave [mailto:DColeman AT US.TIAuto.com]
> Sent: January 31, 2003 6:42 AM
>
> > > * In the middle of some random batch (always the same 
> > > script), we will
> > > get the error, "Error converting NUMERIC to DECIMAL."
...
> > > * this same script (exact down to a strcmp()) will succeed
> > > milliseconds later.
> > > * The severity level of the error is 25, indicating that it is an
> > > internal SQL server failure, not code, driver or query related.
...
> > > * The error code is 3601, which I cannot find anywhere.

> Unless anyone
> has a bright idea why the server would suddenly decide that 
> it can't execute
> the CONVERT function smack in the middle of run-time.  
> I honestly don't think this is a freeTDS issue


Dave, 

Talk to Microsoft.  I'm serious, and in the two years I've been on this
project, that's the first time I've given that advice.  

If you push SQL Server hard enough, sooner or later it will burp.
Sometimes, there are extremely subtle (read, seemingly irrelevant) settings
in the registry -- things that control the operating system, not
specifically SQL Server -- that need adjustment.  They're not documented.  

Other times, like you're describing, you hand SQL Server a perfectly
legitimate query, and it hands you back a nonsensical answer.  Sometimes
consistently, sometimes not, never documented.  Case in point: to the best
of my knowledge, it's not possible to fail converting NUMERIC to DECIMAL.
Something deep in the server is obviously confused.  

Forget questions about Unix, Linux, UDP, FreeTDS.  They are red herrings.
The issue is in the server, contained in the server.  The right hand knoweth
not what the left hand doth.  

Every project I've worked on has turned up one or two of these things.  

The immediate workaround is to re-cast the query.  The more complex the
query and the more rows it handles, the higher the probability it will break
eventually.  Temporary tables are your friend here, as is SQL-92 syntax.  

Your contract with the server is bone simple: you send SQL, it sends
results.  If the query is faulty, so will be the results.  If the query is
good, the results should be good; anything else is a bug.  Write that down,
put it on your wall if necessary.  You'll have to repeat it several times,
unless your sa is both very intelligent and sympathetic.  

Some of my calls have turned up inscrutable but effective system tweaks, or
have been "hotfixed".  The last time I dealt with one of these things, I had
to provide half my database for testing.  They admitted it was a bug, but
they couldn't reproduce it.  Their advice was -- you guessed it -- recast
your query.  

Best of luck, 

--jkl

PS.  

> > >   How much does the core tds API differ from 0.60 release 1?  

I suggest you pull today's include/tds.h from CVS and "diff -ub" them.  That
would be the most concrete answer I can think of.  



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 we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.