Skip to Content.
Sympa Menu

freetds - RE: [freetds] Error: FreeTDS+WINE

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO Frediano" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] Error: FreeTDS+WINE
  • Date: Mon, 22 Sep 2003 19:35:10 +0200

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




Archive powered by MHonArc 2.6.24.

Top of Page