Hi Ryan, I had the same problem on a NT 4 machine. I say had because all my problems disappeared after I made all the statement handle names unique.
I used to create $sth and call finish afterwards and create a new $sth which gave me that famous error. After I renamed them to $sth1, $sth2 etc. (in the same subroutine) this problem disappeared. It seems that even after a finish() call the statement handles stay active but I don't have a clue why. Paul. [EMAIL PROTECTED] wrote: > Perl Guru's, > > I am having a wierd problem connecting to a MS SQLServer 2000 database from > Perl on an NT/2000 box. The symptoms are as follows: > > I'm using DBI and DBD::ODBC to connect to a MS SQLServer 2000 database. > After all code is done executing, and the program is ready to exit, a > system error occurs. A pop-up box with the following message appers: > The instruction at "0x1f9cdb6a" referenced memory at "0x1f9cdb6a". The > memory could not be "read" > Click on OK to terminate the application > Click on CANCEL to debug the application > > If I click CANCEL and debug the process using VisualStudio.NET, I can view > the stack trace. The stack looks like this: > > 1f9cdb88() > odbc32.dll!1f7b7e7b() > odbc32.dll!1f7b7d79() > ODBC.dll!01f43db7() > DBI.dll!100027d6() > perl56.dll!2803bafe() > perl56.dll!2801f042() > perl56.dll!28058027() > perl56.dll!28058539() > perl56.dll!28058539() > perl56.dll!28058539() > perl56.dll!280534f1() > > A have a whole collection of scripts that use DBI and DBD::ODBC, some of > which fail on exit while others don't. And the ones that do fail on exit > are very flaky..by adding a print statement or commenting out code I can > make the scripts fail or not fail (of course it's all trial and error, > since I never know what changes will affect the failure). Incidentally, I > do a finish on all my statement handles, and a disconnect from all my > database connections. However, not doing a finish or a disconnect does not > affect the crashing. > > I've tried swapping out every part of the system I can think of with no > results. Here are some of the configs I've tried: > > OS: > Windows NT (one machine) > Windows 2000 (a different machine) > Perl > ActivePerl v5.6.1 build 631 > IndigoPerl v5.6.1 build 626 > DBI > 1.13 > 1.21 (compiled myself from CPAN) > DBD::ODBC > 0.28 (binary distribution from ActiveState and IndigoStar) > 0.41 (compiled myself from CPAN) > MS SQLServer ODBC Driver > 2000.81.7713.0 > 2000.81.9001.0 > > Something to note is that the error message changes slightly when I use my > self-compiled versions of DBI and DBD::ODBC. The first line of the message > changes to: > The instruction at "0x1f9cdb88" referenced memory at "0x1f9cdb88". > > I've also turned on ODBC tracing and it appear to never return from > SQLFreeStmt at the end of the script: > > [ lots of stuff snipped ] > perl contactInf 17c-177 ENTER SQLDisconnect > HDBC 01F61520 > > perl contactInf 17c-177 EXIT SQLDisconnect with return code 0 > (SQL_SUCCESS) > HDBC 01F61520 > > perl contactInf 17c-177 ENTER SQLFreeConnect > HDBC 01F61520 > > perl contactInf 17c-177 EXIT SQLFreeConnect with return code 0 > (SQL_SUCCESS) > HDBC 01F61520 > > perl contactInf 17c-177 ENTER SQLFreeEnv > HENV 01F61478 > > perl contactInf 17c-177 EXIT SQLFreeEnv with return code 0 (SQL_SUCCESS) > HENV 01F61478 > > perl contactInf 17c-177 ENTER SQLFreeStmt > HSTMT 01F61C40 > UWORD 1 <SQL_DROP> > > I've checked through numerous other resources (usenet groups, ActiveState > bug database), and this appears to be happening to other people as well. > But since the problem is so transient, and I assume hard to replicate on > other systems, nobody ever responds with thoughts about what might actually > fix the problem. The only solution I found was one person who stopped > using the File::Basename package, which I belive just masked the problem in > his specific script. > > You can find other documentation of similar problems at the ActiveState bug > datbase, ticket numbers 17439, 15905, and 15682. Also the usenet article > at the following link: > >http://groups.google.com/groups?hl=en&th=9ce70b8940eef854&seekm=VA.00000008.001c92c0%40fox-europe.com&frame=off > > Thanks in advance for any help/suggestions you can provide. If there is > more information you would like to see, just let me know, and I'd be happy > to provide it. > > Ryan Hope > Systems Engineer > Arris Systems, Inc.
