FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> 
> ZIGLIO, Frediano, VF-IT wrote:
> > > unittest/null.c and unittest/null2.c fail on Sybase 
> servers because
> > > there's no NTEXT or NVARCHAR(MAX).  
> > > 
> > 
> > No, these kind of errors are ignored. However the test isn't able to
> > distinguish if server return differently empty strings and NULLs...
> > Sybase cannot store empty string so it returns empty strings as ' '.
> 
> Hi Freddy, 
> 
> There's so much noise in the output that I couldn't see what 
> was expected
> and what failed.  
> 
> I mostly like your new tests.  They're modular, generally 
> easy to extend
> (even if they're sometimes hard to pass!).  And it's *great* to have
> someone other than the guy writing the feature write the 
> test.  But would
> it be OK to say the output is sometimes not very helpful?  
> 

Yes, I admit that output it's not that easy to read. I have to use a
tool to give colors to streams... the same tool I use to color automatic
tests.

> I like output to be pretty quiet until something goes wrong.  
> Something
> like:
> 
> Trying A ... ok
> Trying B ... ok
> Trying C ... 
> error: file:line: message expected C, got X.
> 

yes, it would be very fine. It's just that you write the test with a lot
of printf and similar and when test is finished... it's finished!

> When I get a chance (or if you do), I'd like to change the 
> null tests not
> to use the "OK anticipated error receive" feature.  I added 
> that feature
> to test provoking errors: If I do X, does the library emit 
> msgno Y?   It's
> not for ignoring messages because a server doesn't support a 
> datatype.  We
> have DBTDS() for that.  
> 
> BTW, I looked for something like dbsetnull() in ODBC.  Didn't find
> anything.  Does it exist?  
> 

No, ODBC application have to support NULLs without substituting with any
default. Personally I don't like global way to set NULLs in dblib
although in ODBC there are statements.

freddy77