freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
Re: [freetds] SQLGetData returns SQL_ERROR by mistake
- From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
- To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
- Subject: Re: [freetds] SQLGetData returns SQL_ERROR by mistake
- Date: Tue, 29 Jan 2008 10:50:26 +0100
>
> James K. Lowden wrote:
> > Perhaps the target type is wrong.
>
> "Perhaps, my pretty one. Perhaps."
>
> http://msdn2.microsoft.com/en-us/library/ms715441(VS.85).aspx
>
> Apologies for the tedious asymptotic approach to the truth.
> I'm sure I
> heard someone say USTL, always good advice.
>
> I passed a SQL datatype identifier (SQL_CHAR) instead of a C type
> identifier. That almost certainly led to a conversion failure.
>
> odbc.c::SQLGetData() has these lines:
>
> *pcbValue = convert_tds2sql(context, nSybType, src,
> srclen, fCType, (TDS_CHAR *) rgbValue,
> cbValueMax, NULL);
> if (*pcbValue < 0)
> ODBC_RETURN(stmt, SQL_ERROR);
>
> I don't see where any diagnostic message is constructed. The
> right one
> appears to be 07006, "Restricted data type attribute violation":
>
Yes, this was reported also in
http://sourceforge.net/tracker/index.php?func=detail&aid=1868995&group_i
d=33106&atid=407808
I wrote a patch
http://freetds.cvs.sourceforge.net/freetds/freetds/src/odbc/odbc.c?r1=1.
469&r2=1.470
http://freetds.cvs.sourceforge.net/freetds/freetds/src/odbc/convert_tds2
sql.c?r1=1.49&r2=1.50
http://freetds.cvs.sourceforge.net/freetds/freetds/src/odbc/odbc_util.c?
r1=1.95&r2=1.96
http://freetds.cvs.sourceforge.net/freetds/freetds/src/odbc/unittests/ge
tdata.c?r1=1.4&r2=1.5
That actually works. I think I'll backport asap.
> "The data value of a column in the result set cannot be
> converted to the
> C data type specified by the argument TargetType."
>
getdata test now include some tests to detect various errors
> For the record, I'm assuming our driver supports the
> SQL_GETDATA_EXTENSIONS options SQL_GD_ANY_COLUMN,
> SQL_GD_ANY_ORDER, and
> SQL_GD_BOUND as returned by SQLGetInfo.
>
> BTW, the function includes this comment:
>
> /* TODO cursors fetch row if needed ?? */
>
> Based on what I see in Microsofts's SQLGetData page, no it's
> not needed:
>
> "SQLGetData can be called only after one or more rows
> have been fetched
> from the result set by SQLFetch, SQLFetchScroll, or SQLExtendedFetch."
>
> I would say calling SQLGetData before fetching should return 24000,
> "Invalid cursor state". Is there more to it than that?
>
I don't remember... perhaps you are right, perhaps I confused SQLFetch
with SQLGetData
> One last thing: SQLGetData appears not to support a target type of
> SQL_ARD_TYPE:
>
> "If TargetType is SQL_ARD_TYPE, the driver uses the
> type identifier
> specified in the SQL_DESC_CONCISE_TYPE field of the ARD."
>
Now it does :) At least in HEAD... but I think these patches should be
merged in 0.82... give me some time to make check with some servers...
freddy77
-
[freetds] SQLGetData returns SQL_ERROR by mistake,
James K. Lowden, 01/28/2008
-
Re: [freetds] SQLGetData returns SQL_ERROR by mistake,
James K. Lowden, 01/28/2008
-
Re: [freetds] SQLGetData returns SQL_ERROR by mistake,
James K. Lowden, 01/29/2008
- Re: [freetds] SQLGetData returns SQL_ERROR by mistake, ZIGLIO, Frediano, VF-IT, 01/29/2008
-
Re: [freetds] SQLGetData returns SQL_ERROR by mistake,
James K. Lowden, 01/29/2008
-
Re: [freetds] SQLGetData returns SQL_ERROR by mistake,
James K. Lowden, 01/28/2008
Archive powered by MHonArc 2.6.24.