> > 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.
Gary -- That's VERY database dependant and, no, technically, SQL Server doesn't support it. Oracle does, for example. There is a way, though, to get it to work for SQL Server. See the perldoc DBD::ODBC for the full description in the section on DBD::ODBC 0.29. However: I remember an e-mail I received from someone with *STRONG* knowledge on this and I believe the e-mail indicated that you can actually put your SQL Server in a "spin loop" where you have to restart the machine. Don't quote me on that, but it sounded like there could be a problem. I can't find it, but I remember reading something about it. Use it at your own risk...:) Regards, Jeff > > 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 > > > > > > > > > > >
