Front page | perl.dbi.dev |
Postings from June 2011
Thanks-- the proposed docpatch was a trial balloon to get this answer. Here's copy for a revised proposed patch: When you really don't know if the statement you have in a variable is going to be a C<SELECT> or not, unrolling the process into C<prepare>,C<execute>, and some C<fetch> variant called within an C<eval> block will always work. On Fri, Jun 17, 2011 at 2:51 AM, Martin J. Evans <martin.evans@easysoft.com> wrote: > > So the proposed change saying > > "When you really don't know if the statement you have in a variable is going > to be a C<SELECT> or not, unrolling the process into C<prepare>,C<execute>, > and some C<fetch> variant will always work, as C<fetch> is defined to > return no data when called on executed non-C<SELECT> statement handles." > > I don't see how DBD::ODBC is supposed to implement that. fetch is just an > alias for fetchrow_arrayref. There is fetch and nothing else. If you call > selectall* it ends up in dbd_st_fetch, if you call fetch it ends up in > dbd_st_fetch. > > So the question becomes which is right DBD::Sybase behaviour or DBD::ODBC. > > MartinThread Previous | Thread Next