On Sat, Feb 21, 2004 at 08:39:24PM -0500, Jeff Urlwin wrote:
> I've been lurking through the $sth->{NAME} issues and it seems to me that
> the current behavior of DBD::ODBC is onerous. If dbd_describe() fails, it
> croaks (which is what DBD::Oracle does).
>
> If we return a Nullsv at this point, the end application does *not* get an
> undef reference, rather it gets a reference to an empty array.
[In general: Never use Nullsv without good reason. Use &sv_undef for undef.]
Returning Nullsv tells the Driver.xst code that you "didn't handle
this attribute FETCH yourself and you want the DBI to handle it":
valuesv = dbd_st_FETCH_attrib(sth, imp_sth, keysv);
if (!valuesv)
valuesv = DBIc_DBISTATE(imp_sth)->get_attr(sth, keysv);
ST(0) = valuesv; /* dbd_st_FETCH_attrib did sv_2mortal */
[But looking at the DBI code (dbih_get_attr_k()) I'm not sure why it
doesn't get into infinite recursion calling FETCH. I'll look into that.]
Anyway, try returning &sv_undef. I think it should also warn(...) if
DBIc_WARN(imp_xxh) is true.
> Currently this affects calling sth->NAME on update, delete, most procedure
> calls, DDL statements, etc.
>
> I think I'd like having it return a null reference instead of a reference to
> an empty array, but I don't know how to manage that at this point.
>
> I know there was some discussion on this recently, but I couldn't find any
> conclusion on google. It's been a day of babysitting my three young kids,
> so please excuse me if I missed it ;)
I need to look back to what I said when this came up before. I think there
are some changes I could make so that FETCH could trigger PrintError/RaiseError.
Currently it can't.
Tim.
