>
> I'm doing some test to get 100% working with FreeTDS (sql
> server odbc driver for *nix) and DBD::ODBC.
>
> Using 1.09 I get some fails (see out1.txt)
>
> Analyzing log (unixODBC and FreeTDS one) it appear that
> binding is wrong for input/output parameters. You bind a
> string composed by one zero character ("\0"), not a NULL. I
> did this change:
Hmmm... I remember on the in/out params that I allocae the buffer sv_buf[0]
and I initialize the buffer to null.>
> diff -r -U10 DBD-ODBC-1.09orig/dbdimp.c DBD-ODBC-1.09/dbdimp.c
> --- DBD-ODBC-1.09orig/dbdimp.c 2004-03-06
> 18:53:58.000000000 +0100
> +++ DBD-ODBC-1.09/dbdimp.c 2004-04-15 21:24:10.000000000 +0200
> @@ -2617,20 +2634,21 @@
> cbColDef = 1;
> if (phs->is_inout) {
> if (!phs->sv_buf) {
> croak("panic: DBD::ODBC binding undef with bad buffer!!!!");
> }
> phs->sv_buf[0] = '\0'; /* just in case, we *know* we
> called SvGROW above */
> rgbValue = phs->sv_buf;
> /* patch for binding undef inout params on sql server */
> ibScale = 1;
> phs->cbValue = 1;
> + phs->cbValue = SQL_NULL_DATA;
> } else {
> rgbValue = NULL;
> phs->cbValue = SQL_NULL_DATA;
> }
> }
> else {
> rgbValue = phs->sv_buf;
> phs->cbValue = (UDWORD) value_len;
> /* not undef, may be a blank string or something */
> if (phs->cbValue == 0)
>
> however I get a infinite loop (see out2.txt). From unixODBC
> log it seems that DBD::ODBC calls in a loop SQLMoreResults,
> SQLMoreResults returns SQL_NO_DATA however DBD::ODBC doesn't
> reset moreResults.
>
> I improved the patch (attached) however I don't understand
> why I get infinite loop with FreeTDS and not with MS ODBC...
I'll have to see what SQLServer returns. It could be that SQLServer's ODBC
driver is returning something else for a value, triggering the stop, but I
can't look at the code now.
> Why you pass a null character instead of a NULL? From comment
> it's a workaround for sql server however it can break other
> drivers, a best way for sql server if to use only output
> parameter (not input/output) cause with sql server you use
> always deferred bind. I did also some changes to t/07bind.t
> however I don't know if these change are so right...
I pass a BUFFER which I initialize to null for the out params, not just the
null character, so I think your patch is wrong and could cause a memory
issue later. Unfortunately, I don't have time to look at it right now. Can
you test against Windows & SQL*Server to make sure you haven't broken
anything there? Windows users & SQL Server, seem to be, by far, the most
popular combination of users of DBD::ODBC and I would not want to break
things that are working there.
Thanks,
Jeff
