FreeTDS Development Group

["James K. Lowden" <jklowden AT schemamania.org>]

Begin forwarded message:

Date: Tue, 27 Apr 2004 13:02:25 +1000
From: Carl Lewis <carl AT dpiwe.tas.gov.au>
To: jklowden AT freetds.org
Subject: patch for codes return in wrong part of odbc struct.


...

The patch(es) fix a problem with SQLGetInfo() (src/odbc.c) that shows up
accessing a sqlserver (6.0) DB using the msjet dll's (3.5 and/or 4.0)
under WINE accessing freeTDS through unixODBC.
The error that appears is a

"Reserved Error (-7701)
  there is no message for this error. (3000)."

Tracking it down I found odbc.c is returning the right value from
SQLGetInfo() (for SQL_ODBC_API_CONFORMANCE) but in an unexpected field.
I don't know enough about it to guess if it the return value is required
in the field that is currently used by other applications, so the patch
below simply changes odbc.c to return it in both.
When SQL_TXN_CAPABLE is the parameter to SQLGetInfo() a
similar error is generated and the fix is identical.


I've attached two patches (against 0.63.dev.20040426)
the first just patches the two cases above (patch.small).
The second (patch.larger) patches those two and others that a quick 
perusal of the ODBC Specification Compliance Errors (-7700 to -7799) at
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnaraccessdev/html/odc_jetdatabaseengineversion30odbcconnectivity.asp
shows may be effected, to whit:
SQL_CURSOR_COMMIT_BEHAVIOR, SQL_CURSOR_ROLLBACK_BEHAVIOR,
SQL_STRING_FUNCTIONS, SQL_NUMERIC_FUNCTIONS, SQL_TIMEDATE_FUNCTIONS,
SQL_SYSTEM_FUNCTIONS,
SQL_CONCAT_NULL_BEHAVIOR,  SQL_CONVERT_FUNCTIONS, SQL_CONVERT_SMALLINT, 
SQL_CONVERT_INTEGER,
SQL_CONVERT_FLOAT, SQL_CONVERT_DECIMAL, SQL_CONVERT_TIMESTAMP, 
SQL_CONVERT_VARCHAR
Unfortunately I have no way of testing the second patch.
However it has shown that my problem may be related to a lack of cursor
support :-( as I now get an error message for SQL_CURSOR_COMMIT_BEHAVIOR 
and SQL_CURSOR_ROLLBACK_BEHAVIOR indicating the application wants 
SQL_CB_PRESERVE over the SQL_CB_CLOSE that is currently returned.


For the following I'm assuming the behaviour of odbc_set_string 
odbc_util.c) means that they will be ok:
SQL_DATA_SOURCE_READ_ONLY, SQL_IDENTIFIER_QUOTE_CHAR, SQL_OUTER_JOINS, 
SQL_EXPRESSIONS_IN_ORDERBY,

I can't find support for these in odbc.c:
SQL_C_BIT, SQL_C_SHORT, SQL_C_TIMESTAMP, SQL_C_TIMESTAMP

If you'd like the patches prepared differently or changed let me know,
I'm more than happy to contribute back (albiet short term :-)

Cheers, hoping this makes sense and is of some use,
Carl Lewis
SysAdmin (amongst other things)
Department of Primary Industries Water and Environment
Tasmania
Australia.