RE: Error: FreeTDS+WINE

> From: Rainer [mailto:sourceforge@xxxxxxxxxxx]
> Sent: September 22, 2003 10:36 AM
> 
> 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.  :-)

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

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

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


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

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

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.  

Regards, 

--jkl

[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?  

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