RE: Error: FreeTDS+WINE

> > 
> > I tried with both iODBC and unixODBC, both TDS7.0 and 8.0, 
> same error. 
> > So I commented out AC_CHECK_FUNCS(SQLGetPrivateProfileString) in 
> > configure.in. So far so good. (Any idea of what is causing 
> configure 
> > to find the function, and later on say its symbol is undefined?)
> 
> Not sure what we're up to there.  That's one for Frediano.  :-)
> 

Mmmm... from configure.in

if test x$odbc = xtrue; then
        save_LIBS="$LIBS"
        if test x$unixodbc = xtrue; then
                LIBS="$LIBS -lodbcinst"
        else
                LIBS="$LIBS -liodbcinst"
        fi
        AC_CHECK_FUNCS(SQLGetPrivateProfileString)
        LIBS="$save_LIBS"
fi

So lib (odbcinst or iodbcinst) is not added

However in src/odbc/Makefile.am

if UNIXODBC
libtdsodbc_la_LIBADD=   ../tds/libtds_objects.la -lodbcinst
$(NETWORK_LIBS) $(LIBICONV) ../replacements/libreplacements.la
else
libtdsodbc_la_LIBADD=   ../tds/libtds_objects.la $(NETWORK_LIBS)
$(LIBICONV) ../replacements/libreplacements.la
endif

So should work with unixODBC (it work on my machine with unixODBC)

I never used FreeTDS with WINE... how work wine building so library ?? I
thiugh it build .dll library...

> > I've also noticed in the changelogs that Freddy
> > corrected the SQL_SUCCESS_WITH_INFO / 01S02 / "Invalid
> > option" problem.
> > But the "Invalid option" problem returned, and only went away 
> > when I changed
> > the following case statement in odbc.c:4759
> > 
> >     default:
> >             odbc_errs_add(&stmt->errs, "HY092", NULL, NULL);
> >             ODBC_RETURN(stmt, SQL_ERROR);
> > 
> > to
> > 
> >     default:
> >             odbc_errs_add(&stmt->errs, "HY092", NULL, NULL);
> >             ODBC_RETURN(stmt, SQL_SUCCESS_WITH_INFO);
> 
> You're masking the problem there.  The state "HY092" *is* an 
> error, and should be reported as such.  It would be much 
> better to log the unhandled value and track down what's happening.  
> 
> AFAICT, HY092 is not a valid SQLSTATE for SQLColAttribute().  
> We should use HY091 instead.  

James is right... 
However the function is SQLSetStmtAttr, not SQLColAttribute. We have to
find missed attribute...
A printf of a log should help, as in

        default:
                tdsdump_log(TDS_DBG_INFO1, "unknown stmt attribute
%d\n", (int)Attribute);
                odbc_errs_add(&stmt->errs, "HY092", NULL, NULL);
                ODBC_RETURN(stmt, SQL_ERROR);

> 
> > "S1091: [FreeTDS][SQL Server] Descriptor type out of range"
> > 
> > I did some research, and it basically means:
> > "The descriptor type, which was given to the ODBC function
> > SQLColAttributes() as an argument is not valid. Change the 
> type to an 
> > valid decriptor type."
> 
> Yes, and we correctly map it to the newer "HY091".  I don't 
> know under what circumstances you'd get "S1091" instead of 
> "HY091".  Perhaps that comes from the DM.  
> 

Perhaps you are using version 2, HY091 is a odbc code (translated
automatically by FreeTDS)

> > > One possible culprit: WINE tried to read SQL_ATTR_ROW_NUMBER with 
> > > SQLGetStmtAttr().  You might want to put a logging 
> statement there 
> > > (odbc.c:2919) to see if it's returning zero.
> > 
> > Should I put the logging statement as you suggested, or does
> > the "descriptor type out of range" error mean something else?
> 
> I think this is all connected.  We want to know the first 
> request WINE makes that our ODBC can't answer properly, 
> whether because our implementation is incomplete, or because 
> the application is asking something silly.  By not returning 
> an error for HY092, we probably delay the day of reckoning a 
> little bit, but the DM or someone eventually sees the 
> SQLSTATE and gives up.
> 

As you know I'm against returning "is possible" if not...

> 
> > > Can you execute spLicenca under unixODBC's isql?
> > 
> > Yes, I can execute it with isql and iodbc's odbctest.
> > I confirmed with the people responsible for developing the
> > application...
> > the columns and rows returned by freetds are correct.
> 
> If isql can read the results, that's an indication that we 
> provide the basic functionality necessary to use spLicenca.  
> Your application is clearly doing something that isql is not. 
>  It may be (see below) it's using ODBC 2.0 constants we don't 
> expect.  

Using ODBC you can call a procedure without building language string...

I hope you are using latest CVS. 0.61 is still not ready for this
stuff...
Yesterday I fixed last issue with iconv (using GNU iconv). If you use
Linux/FreeBSD you shouldn't have problems with CVS.

> 
> > "odbc:SQLColAttribute: fDescType 3 not catered for..."
> > Is this error relevant?
> 
> Yes.  SQLColAttribute() takes what we call "fDescType" and 
> Microsoft calls
> "FieldIdentifier" as the third parameter.   The documented 
> type constants
> for that parameter all have names beginning with "SQL_DESC_". 
>  Grepping through the odbc headers[1], I don't find anything 
> for "3", but some SQL_DESC constants are defined in terms of 
> SQL_COLUMN* types, and I see SQL_COLUMN_LENGTH is defined as 
> 3.  In the ODBC documentation for SQLColAttribute(), there is 
> this note:
> 
> "The #define values of the ODBC 2.x FieldIdentifiers 
> SQL_COLUMN_LENGTH, SQL_COLUMN_PRECISION, and SQL_COLUMN_SCALE 
> are different from the #define values of the ODBC 3.x 
> FieldIdentifiers SQL_DESC_PRECISION, SQL_DESC_SCALE, and 
> SQL_DESC_LENGTH. An ODBC 2.x driver need only support the 
> ODBC 2.x values. An ODBC 3.x driver must support both 
> "SQL_COLUMN" and "SQL_DESC" values for these three FieldIdentifiers."
>  
> Oh, goodie.  That suggests you could add a line after 
> src/odbc/odbc.c:1416,
> thus:
> 
>         case SQL_DESC_LENGTH:
>        case SQL_COLUMN_LENGTH:
>                 IOUT(SQLINTEGER, drec->sql_desc_length);
>                 break;
> 

CVS code should handle SQL_COLUMN_LENGTH in SQLColAttributes but not in
SQLColAttribute (as documented SQLColAttribute do not handle
SQL_COLUMN_*)... 
I'll look deeply in documentation... ARGHHHH... I realize the problem...

> You might want to add SQL_DESC_PRECISION and SQL_DESC_SCALE, 
> too, while you're at it.  ;-)
> 
> It also seems to indicate the application is making ODBC 2.0 
> calls.  :-/  If you can confirm that, then we'll know what to 
> look out for.  The
> SQLColAttribute() documentation has several "Backward 
> Compatibility" notes that might serve as guideposts.  
> 
> I hope that helps.  It seems like you're making some progress.  
> 
> 
> [1] A gripe: For many defined and enumerated types, we have 
> reverse lookup tables that return the name of a value.  It 
> sure would be nice to have such a function for ODBC's 
> parameters.  Perhaps the DMs have something already?  
> 

No, DM has nothing....

freddy77