Skip to Content.
Sympa Menu

freetds - Re: [freetds] SQLGetData returns SQL_ERROR by mistake

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • 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




Archive powered by MHonArc 2.6.24.

Top of Page