in reply to DBI bind_param_inout trick

Just out of interest I tried this with DBD::ODBC after removing the "from dual" and changing the bind_param_inout calls to remove the ':' (which is not supported in DBD::ODBC - see note in DBD::ODBC). The output is worryingly different from DBD::Oracle:

DBD::Oracle output:
abc 123
abc 456

[download]
DBD::ODBC output:
 123
 456

[download]

Replies are listed 'Best First'.
Re^2: DBI bind_param_inout trick
by mje (Curate) on Sep 03, 2012 at 16:58 UTC

    Looks like a bug in DBD::ODBC. Parameters are bound initially in ODBC at bind time and if they change at execute time they have to be rebound ODBC-wise. The following code is what tests whether a parameter needs to be rebound:

    if (SvTYPE(phs->sv) != phs->sv_type /* has the type changed? */
   || (SvOK(phs->sv) && !SvPOK(phs->sv)) /* is there still a string? *
+/
   || SvPVX(phs->sv) != phs->sv_buf /* has the string buffer moved? */
                ) {
                if (!rebind_param(sth, imp_sth, imp_dbh, phs))
                    croak("Can't rebind placeholder %s", phs->name);
               }

    [download]

    Trouble is I didn't write that code which attempts to rebind the parameter ODBC-wise and although I understand the first and last test in the if condition the comment next to "(SvOK(phs->sv) && !SvPOK(phs->sv))" does not seem to agree with the code. I wonder what the original author meant. It also does not cater for a parameter being undef then a string.

[reply]
[d/l]
[reply]
        Awesome! I expected this to not be supported in some DBDs, but if it fleshes out bugs where it is supposed to be supported, then it's done more than originally intended!
[reply]

In Section Meditations