FreeTDS Development Group

["Rainer" <sourceforge AT powered.net>]

>> > A quick fix [...] would be to change
>> > those 7 cases to return SQL_SUCCESS_WITH_INFO
>>
>> I've made the changes to the source code (odbc.c) as you
>> suggested, and
>> the error while running the application with wine has changed to:
>> "Run-time error 40009: No current row".
>
> Hmm.  Not sure what's going on.
>
> You issue the "EXECUTE dbo.spLicenca ..." query, and no rows are returned.
> That procedure issues 7 queries that return no results (that's what the
> successive DONEINPROC packets mean).  Then you get a 1-column result set;
> the column name is 'aux':
> [...]
> The row data show a one-byte integer whose value is 0x30.
> [...]
> It seems possible to me that the preceding queries that don't return
> results
> might be confusing libtds and/or our ODBC driver, but that's just
> speculation.  I mention it only because there are other recent reports of
> problems retrieving results after such a query.  Cf. Steve Hanselman's
> message last week, for instance.
> Can you execute spLicenca under unixODBC's isql?  If yes, then it's
> specific
> to WINE (although it might still be a FreeTDS issue).  If not, the problem
> should be easier to isolate.
> [...]


Upon trying the latest CVS, I've noticed that the configure script now
checks for SQLGetPrivateProfileString. (and finds it)
When running my app with WINE, I got the following error:
"40002 - 00000: [iODBC][Driver Manager]
/usr/local/freetds-cvs-iodbc/lib/libtdsodbc.so: undefined symbol:
SQLGetPrivateProfileString"

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

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


Ok, looks like this problem was solved.
The stored procedure is executed, but after some time I get this new 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."

You mentioned this function on your last e-mail:

> The next thing in the log shows is a bunch of calls to SQLColAttribute(),
> and there it ends.
> The error message apparently comes from WINE; it doesn't come from FreeTDS
> that I can see.  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.

All the errors I'm getting are somehow related to column and row attributes.
Should I put the logging statement as you suggested, or does the "descriptor
type out of range" error mean something else?

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

I've posted the latest log file here:
http://www.powered.net/rainer/freetds-09-22.log

"odbc:SQLColAttribute: fDescType 3 not catered for..."
Is this error relevant?

Best regards,
Rainer