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...


WINE uses its own ODBC32.DLL (inside the 'fake' windows\system32), which
in turn directs odbc calls to /usr/lib/libodbc.so, which is a dynamic link
to /usr/local/unixodbc/lib/libodbc.so or /usr/local/iodbc/lib/libiodbc.so.


>
>> > 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);
>

Here is the log result:
...
12:46:35.063443 tds_process_end: more_results = 0
12:46:35.063477                  was_cancelled = 1
12:46:35.063525                  error = 0
12:46:35.063555                  done_count_valid = 0
Unknown STMT Attribute 9
SQLFreeHandle(3, 0x81bb738)

>>
>> > "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)
>

I'm not sure if WINE is using v2 or v3... is there a way to know this
(does the tdsdump include this info?)

>> > > 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.
>

Yes, I'm using the latest CVS (from today).

>>
>> > "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