> > By the way, the last call to fetchrow_array() (that returns
> > 'undef') implicitly calls finish() internally.
> I assume this is the same finish of the handle obtained from my
> prepare. But because I have a reference to the handle holed away it
> is not really "finished" and that is why I
Thanks Mark,
That confirms what I have been observing.
I have been running a test for about 12 hours doing the reused prepare and
I detect no leakage.
A question about your reply about the automatic finish at the last
fetchrow. I assume this is the same finish of the handle obtained from my
> I think I know the answer to this so I'm looking for some
> conformation. What I do is to prepare a relatively large and complex
> query. Then I run the same query forever never doing a finalize. My
> assumption is I will have no memory leakage.
In principle this should be fine, and if it
On 4 Oct 2014, at 11:16pm, Jim Dodgen wrote:
> It might be I need more of a Perl DBI question
Whoops. Yes, my answer was geared to users of the C API and thin shims to it.
I have no idea how Perl DBI works. Sorry about that, and I hope you can get a
response from a Perl
It might be I need more of a Perl DBI question the order of the statements
I do are as follows
prepare >> - Done once
execute << done many times
followed by:
fetchrow_array << until exhausted
finish << never done
I just don't see that the Execute/Fetchrow-array activity is going to leave
a
On 4 Oct 2014, at 10:08pm, Jim Dodgen wrote:
> What I do is to prepare a relatively large and complex query. Then I run
> the same query forever never doing a finalize. My assumption is I will
> have no memory leakage.
You can do _step() and _reset() and _bind_() as many times
I think I know the answer to this so I'm looking for some conformation.
What I do is to prepare a relatively large and complex query. Then I run
the same query forever never doing a finalize. My assumption is I will
have no memory leakage.
*Jim Dodgen*
7 matches
Mail list logo