[freetds] Arguments to SQLColAttribute

Frediano Ziglio freddy77 at gmail.com
Thu Jul 30 13:34:07 EDT 2020


Il giorno gio 30 lug 2020 alle ore 16:29 Bruce Seely <bseely at stsci.edu> ha
scritto:

>
> In sql.log, the trace for SQLColAttribute looks like this:
>
> [000000.200163]
> alisp           1120FD5C0 ENTER SQLColAttribute
>                 SQLHSTMT          0x7f92b46023f0
>                 SQLUSMALLINT      1
>                 SQLUSMALLINT      1011 (SQL_DESC_NAME)
>                 SQLPOINTER        0x7ffeea1dafc0
>                 SQLINTEGER      * 256
>                 SQLSMALLINT     * 0x7ffeea1db1d0
>                 SQLLEN               * 0x0
>
> [000000.201194]
> alisp           1120FD5C0 EXIT  SQLColAttribute with return code -1
> (SQL_ERROR)
>                 SQLHSTMT          0x7f92b46023f0
>                 SQLUSMALLINT      1
>                 SQLUSMALLINT      1011 (SQL_DESC_NAME)
>                 SQLPOINTER        0x7ffeea1dafc0
>                 SQLINTEGER      * 256
>                 SQLSMALLINT     * 0x7ffeea1db1d0
>                 SQLLEN               * 0x0
>
>
> The SQLColAttribute  definition in odbc/odbc.c is this:
> static SQLRETURN _SQLColAttribute(SQLHSTMT hstmt, SQLUSMALLINT icol,
> SQLUSMALLINT fDescType, SQLPOINTER rgbDesc,
>                                           SQLSMALLINT cbDescMax,
> SQLSMALLINT FAR * pcbDesc, SQLLEN FAR * pfDesc _WIDE);
>
> The SQLColAttribute  spec at
> https://www.ibm.com/support/knowledgecenter/SSEPEK_10.0.0/odbc/src/tpc/db2z_fncolattribute.html
> shows it as a SQLSMALLINT
>
>
> The BufferLength (5th) argument is a SQLSMALLINT in the C code, but it
> shows as a SQLINTEGER* in the sql.log trace.
>
> Is this an indication that I am passing a bad 5th argument to
> SQLColAttribute?
>
>
Hi,
  I would have suggested a SQL trace too.

The declarations in FreeTDS are:


#if (ODBCVER >= 0x0300)
SQLRETURN ODBC_PUBLIC ODBC_API
SQLColAttribute(SQLHSTMT hstmt, SQLUSMALLINT icol, SQLUSMALLINT fDescType,
                SQLPOINTER rgbDesc, SQLSMALLINT cbDescMax, SQLSMALLINT FAR
* pcbDesc,
#ifdef TDS_SQLCOLATTRIBUTE_SQLLEN
                SQLLEN FAR * pfDesc
#else
                SQLPOINTER pfDesc
#endif
        )
{

        return _SQLColAttribute(hstmt, icol, fDescType, rgbDesc, cbDescMax,
pcbDesc, pfDesc _wide0);
}

#ifdef ENABLE_ODBC_WIDE
SQLRETURN ODBC_PUBLIC ODBC_API
SQLColAttributeW(SQLHSTMT hstmt, SQLUSMALLINT icol, SQLUSMALLINT fDescType,
                SQLPOINTER rgbDesc, SQLSMALLINT cbDescMax, SQLSMALLINT FAR
* pcbDesc,
#ifdef TDS_SQLCOLATTRIBUTE_SQLLEN
                SQLLEN FAR * pfDesc
#else
                SQLPOINTER pfDesc
#endif
        )
{
        tdsdump_log(TDS_DBG_FUNC, "SQLColAttributeW(%p, %u, %u, %p, %d, %p,
%p)\n",
                        hstmt, icol, fDescType, rgbDesc, cbDescMax,
pcbDesc, pfDesc);

        return _SQLColAttribute(hstmt, icol, fDescType, rgbDesc, cbDescMax,
pcbDesc, pfDesc, 1);
}
#endif
#endif

the same as the page you pointed out (and compatible also with Microsoft
documentation).
I have no idea why the log shows a pointer and to be honest I would expect
more a crash than the
function just returning error if the DM would interpret the parameter in
such a way.
It's also weird that the value is written in decimal and not in hexadecimal
like all other pointers.
Which kind of DM is it?


Thanks,
> Bruce
>

Frediano


More information about the FreeTDS mailing list