On Mon, 18 Nov 2002 13:49:27 -0500 (EST) Paul Boutros <[EMAIL PROTECTED]> wrote:
> Thanks for your reply. I turned on trace(2, "trace.txt") on the advice of > one responder. Let me summarize my code a little more clearly now -- this > is a simpler fragment than I posted previously, and still displays the > error. > > sub process($$$); > > $sql_a = ""; > $sql_b = ""; > $sth_a = $dbh->prepare($sql_a); > $sth_b = $dbh->prepare($sql_b); I'm not sure about Access, but some underlying databases don't like multiple statements open at the same time on a single database handle. Just for testing, try opening separate database connections for each statement and see if that helps. # For example (untested): $sth_a = $dbh_a -> prepare( $sql_a ); $sth_b = $dbh_b -> prepare( $sql_b ); > So, I both finish the statement-handle at the end of the sub, and I do > instantiate a new sth variable with function-level scope each time. I > worry about the idea of *assigning* one sth to another -- in other words > I'm not sure it's legitimate to be doing: > $sth = $sth_a; The finish() shouldn't be necessary since you are looping until all rows are fetched. finish() is basically a hint to DBI that you won't be fetching more rows unless you execute() the handle again. $sth = $sth_a just assigns the same handle to another variable. It is perfectly legitimate, both variables contain the same value which is a reference to the statement information. Since $sth goes out of scope as soon as the procedure returns, it has no impact outside the procedure. Any operations performed on the statement through it are indistinguishable from those done using $sth_a. -- Mac :}) ** I normally forward private questions to the appropriate mail list. ** Ask Smarter: http://www.tuxedo.org/~esr/faqs/smart-questions.html Give a hobbit a fish and he eats fish for a day. Give a hobbit a ring and he eats fish for an age.
