Jeff and Tim;
Sorry for this digression.
I tried rebuilding the DBI and DBD::ODBC and re-running. As always in debugging,
you almost always get another question, rather than an answer. Maybe the original
build was bad, and this is the real issue. Upon running the code, I get:
DBD::ODBC::st execute failed: [Microsoft][ODBC SQL Server Driver]Connection is b
usy with results for another hstmt (SQL-S1000)(DBD: st_execute/SQLExecute err=-1
) at TestStep_Record.pm line 410, <STDIN> line 1.
Am I to understand from this that ODBC connections do not permit nested
queries to use the same connection handle? I'm sure ADO does. The code queries
the database, then uses the result of each record to launch another query on a second
table.
Regards;
Gary
>>> Tim Bunce <[EMAIL PROTECTED]> 07/30/2002 8:51:25 AM >>>
On Tue, Jul 30, 2002 at 08:21:39AM -0400, Gary Gauthier wrote:
> Jeff and Tim;
>
> The program only uses non-parameterized SELECT statements,
> accesses an SQL2000 database using DBD:ODBC,
> and data is always read using bound variables. Unfortunately;
> it is a VERY large application, all object-oriented, and doesn't
> lend itself to being made smaller to test for leaks.
You could try going in the other direction... write a small script
that does the same kind of thing and see if it leaks.
If it doesn't then we're likely to point the finger at your application.
Probably worth trying it with an older version of the DBI as a check.
And/or with an older DBD::ODBC version.
> How does one use the Devel::Leak module to the best advantage?
Read the docs. It's not too complicated
http://search-beta.cpan.org/author/NI-S/Devel-Leak/Leak.pm
Tim.
> It may be the easiest way to check it out.
>
> Regards;
> Gary
>
>
> >>> Tim Bunce <[EMAIL PROTECTED]> 07/29/2002 4:38:39 PM >>>
> On Mon, Jul 29, 2002 at 09:52:33AM -0400, Jeff Urlwin wrote:
> > Gary -- it's more likely in DBD::ODBC than DBI.
>
> But not by much :)
>
> Probably worth trying it with an older version of the DBI as a check.
>
> > If you can create a
> > self-contained sample, it would be greatly appreciated and looked at faster
> > :)
>
> Yes, a _small_ simple self-contained example script is a big help.
> Copy the problem script and keep cutting away at it till the leak
> goes away, or it gets so small it's obvious where the problem is.
>
> > You didn't indicate if the loop is a set of inserts, queries, etc. Does it
> > have longs? What's the LongReadLen value?
> >
> > If you can, include a drop table and create table statement at the top,
> > insert test data, then run through something similar to your loop that's
> > leaking.
> >
> > Tim -- if you have suggestions as to how to approach this with Perl, I'd be
> > very appreciative!
>
> The "keep making the sample code smaller" approach usually works well.
>
> The Devel::Leak module may be useful:
> http://search-beta.cpan.org/author/NI-S/Devel-Leak-0.02/Leak.pm
>
> Another approach is to let the process grow huge (many MB) then
> core dump it and look through the binary (using less or other viewer
> that can read binary) and look for clues/patterns in the leaked memory.
>
> Tim.
>
> > Regards,
> >
> > Jeff
> > >
> > > Tim;
> > >
> > > I'm using DBI v1.30 and DBD-ODBC v0.43. My database(SQL2000) app
> > > is invoked about 40,000 times over the course of about 2 days to
> > > generate test scripts for some automated test equipment. I've
> > > been noticing the memory usage creeping up over the course of the
> > > runs (up to Meg per loop at times). I have seen a report on the
> > > developers mail list regarding this problem in recent versions.
> > > Have you done any tests to check for leaks, or have you had any
> > > reports of leaks? Perhaps there is some peculiarity of SQL2000,
> > > that requires explicit releasing of handles or buffer space?
> > >
> > > Any help would be appreciated.
> > >
> > > Regards;
> > > Gary
> > >
> >
> >
