Shibboleth Developers

["Scott Cantor" <>]

> Regarding updateRow, I think that you need to close the cursor
> associated to the statement handle, because it was opened for the
> SQLExecDirect at the beginning of the method, by using something like:

That makes sense.

> Maybe it's the same cursor problem.

No, the insert doesn't have any prior use of the handle, it's only running
one statement. Best I can tell, it's not even calling into the freetds ODBC
driver either. The logs suggest it's failing in the ODBC manager, so I have
a hard time seeing how this works on any other driver. There must be state
aasociated with the connection that's incompatible with prepared statements
in some way.

When I traced the SQL Server, I can see that it prepares the statement, but
it never executes it. The ODBC layer just refuses to run it.

The worst problem I'm having is that when SQLExecute fails, I get a double
free if I free the statement handle. We're going to have to verify that it
doesn't leak if I let the connection free the statements for me.

-- Scott