[ic] Flypage, multiple product tables, and [item-field]

[Todd L. Cawthron]

> "Todd L. Cawthron" <todd@lunsfordgroup.com> writes:
>
>
> [...]
>
> >
> > After I posted this message to the list, I did some more investigating
and
> > then raised the issue on bugzilla.
> >
> > When I turned on the debugging features in Interchange, I noticed a lot
of
> > database error messages during flypage generation.  The first error that
was
> > returned (which resulted from querying the DescriptionField) started a
chain
> > reaction that tripped up the rest of the flypage process on the database
> > side.  I added a line of code to DBI.pm on my system that fixed this
> > problem.  However, I can't guarantee at this point that my "fix" didn't
> > break something else!
>
> From DBI:
>
>            The finish method does not affect the transaction
>            status of the session.  It has nothing to do with
>            transactions. It's mostly an internal 'housekeeping'
>            method that is rarely needed. There's no need to call
>            finish if you're about to destroy or re-execute the
>            statement handle.  See also the disconnect entry
>            elsewhere in this document and the the Active entry
>            elsewhere in this documentattribute.
>
> So, I suppose this is a bug in the Sybase stuff.
>
> Ciao
>         Racke
>

You're right, this may be a Sybase or a DBD::Sybase bug; particularly
because it doesn't look like anybody else has run into this problem.  But, I
add this bit of information for the sake of argument...

This is what caught my attention originally, also from DBI:

        'finish'

            Indicates that no more data will be fetched from this statement
handle before it is
            either executed again or destroyed...

            When all the data has been fetched from a 'SELECT' statement,
the driver should automat
            ically call 'finish' for you.  So you should not normally need
to call it explicitly...

            The 'finish' method should have been called 'cancel_select'.

Given this context, the way I interpret the section of the documentation
that you quoted is:

    There's no need to call finish if you're about to destroy
(because 'finish' is called implicitly before the statement handle is
destroyed, from DBI::DBD)

    or re-execute the statement handle.
(because 'finish' was already called after all rows in the result set had
been fetched)

In this case, however, not all data has been fetched from the 'SELECT'
statement, so the driver did not automatically call 'finish'.  Instead, it
had to be called explicitly before the statement handle could be
re-executed.


Todd L. Cawthron
todd@lunsfordgroup.com