#21 SQLSetStmtAttr(): value=SQL_NULL_DESC => SQL_INVALID_HANDLE

[om_user]

SQLSetStmtAttr(): Can`t set SQL_ATTR_APP_PARAM_DESC
(and SQL_ATTR_APP_ROW_DESC) stetement attribute to
SQL_NULL_DESC after it was set to explicitly allocated
descriptor.

Expected result:
statement handle must reverts to the implicitly
allocated APD(ARD) handle
Actual result:
DriverManager (unixODBC-2.2.11) return SQL_INVALID_HANDLE.

[Nick Gorham]

Logged In: YES
user_id=7184

Yes, you are right.

I have added this to CVS, and there is a snapshot with this
change in on ftp://ftp.easysoft.com/pub/unixODBC

If you can let me know if this works for you it would help me.

Thanks.

[om_user]

Logged In: YES
user_id=1503847

Thanks, now it`s works fine in unixODBC-2.2.12

[Nick Gorham]

Logged In: YES
user_id=7184

Thanks. I will close this then.

[om_user]

Logged In: YES
user_id=1503847

Sorry, seems I litle hurry with concluding that this now
works fine, please check setting SQL_ATTR_APP_ROW_DESC to
SQL_NULL_DESC it`s still return SQL_INVALID_HADLE, thouth
drive after procesing this value return SQL_SUCCESS.
Maybe it help you, after litle fix
SQLSetStmtAttr.c in line 447 insert something like this
//*******************************
if ( log_info.log_flag )
{
sprintf( statement -> msg,
"\n\t\tExit:[%s]",
__get_return_status( ret, s1 ));
dm_log_write( __FILE__,
__LINE__,
LOG_INFO,
LOG_INFO,
statement -> msg );
}

return function_return( SQL_HANDLE_STMT, statement, ret );
//*****************************
after that error disappear (you do the same for
SQL_ATTR_APP_PARAM_DESC).

FYI. MS DM in this case (setting SQL_NULL_DESC) doesn`t
call setstmtattr in driver with ValuePtr = null, looks like
he change null to implicit handle.

[Nick Gorham]

Logged In: YES
user_id=7184

Ok, that all makes sense, I will make that change tomorrow,
and get a new snapshot of 2.2.12 for you.

[Nick Gorham]

Logged In: YES
user_id=7184

Ok, with luch I have recovered from the brain fade, and this
should be ok now. Change in CVS, and another 2.2.12 snapshot
done.