FreeTDS Development Group

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

> 
> $ grep ^FAIL src/odbc/nohup.out 
> FAIL: genparams
> FAIL: cursor1
> FAIL: scroll
> FAIL: describecol
> 

:(
describecol is expected
scroll and cursor1 are work in progress but should work with a mssql2k
(I don't know with mssql2005, I know they not work on sybase)
genparams... this is a problem. It should work! Looking at log it seems
a problem with bigint (64 bit). You should check if configure detect
correctly 64 bit type.

> I installed unixODBC-2.2.12 at home, and then built
> --with-odbc-nodm=/usr/local.  
> 
> First problem was I couldn't compile the unit tests because 
> of line 70 in
> common.c:
> 
> 
>       in = fopen(".." TDS_SDIR_SEPARATOR ".." TDS_SDIR_SEPARATOR ".."
> TDS_SDIR_SEPARATOR "PWD", "r");
> 
> The TDS_SDIR_SEPARATOR is unnecessary IMO.  Microsoft's C 
> runtime library
> accepts '/' as a directory separator, cf.
> http://www.cs.colorado.edu/~main/cs1300/include/stdio.h.  I'm 
> not sure why
> it didn't compile.  I changed the line to use the same path as in the
> dblib unit tests. (Do they work in Win32?)  
> 

Probably works. Consider that windows nt is posix something compliant.
However the code you spot compile on my machine (even on windows...)

> Then everything compiled.  On linking, I got these errors:
> 
> *** Warning: Linking the executable [name] against the loadable module
> *** libtdsodbc.so is not portable!
> 
> Is that normal?  
> 

thay are warnings and yes they are normal. I think libtool should use
-rpath instead of raisnig a warning but currently it throw the warning.

> The good news is that only 4 of the 45 tests failed, log 
> attached.  The
> bad news is that's not the same set as failed on
> http://freetds.sourceforge.net/out/test/.  
> 

array and raiserror fail only if compiled with --enable-developing flag.

> I then tried out unixODBC's isql.  (One annoying misfeature 
> is that you
> have to use the -v option to see some error messages.)  I 
> reproduced an
> error Nick reported some time ago:
> 
> $ isql -v $S $U $P 
> ...
> SQL> print 'hello' print 'goodbye'
> [][unixODBC][FreeTDS][SQL Server]goodbye
> [][unixODBC][FreeTDS][SQL Server]hello
> [ISQL]INFO: SQLExecute returned SQL_SUCCESS_WITH_INFO
> SQLRowCount returns -1
> 
> I believe those messages are retrieved by SQLError in the DM; when I
> modify the code to call SQLGetDiagRec and display the 
> messages ordered by
> RecNumber, I get this:
> 
> SQL> print 'hello' print 'goodbye'
> [][unixODBC][FreeTDS][SQL Server]goodbye
> [][unixODBC][FreeTDS][SQL Server]hello
> [ISQL]INFO: SQLExecute returned SQL_SUCCESS_WITH_INFO
> error 0 []: [FreeTDS][SQL Server]hello
> error 0 []: [FreeTDS][SQL Server]goodbye
> SQLRowCount returns -1
> 
> (The empty brakets [] indicate Sqlstate is not set.)
> 
> Puzzling.  
> 

SqlState not set ?? Quite strange... there are many places where state
is checked and replaced by a default...
My isql do not even print messages :(

freddy77