I've seen that with the FoxPro driver and chalked it up to something that the specific driver was doing. I've never had a problem with SQL Server. I have had problems with Oracle's driver when passing NULL for an IN/OUT parameter, which I think is still a bug in DBD::ODBC.
I'm sure it's not easy, but if you have a small sample I can walk through. I can try to run with BoundsChecker (but it's painful to setup for Perl). Are you binding parameters? Do you have longs? Is there anything 'non-vanilla' with your setup? I'm using SQL Server driver 2000.80.194.00 I had to update it when I was testing a bug where SQL server choked on a certain column name. Where did you get your versions of the driver? Jeff > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 16, 2002 9:41 AM > To: [EMAIL PROTECTED] > Subject: DBD::ODBC crashes on exit > > > 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.
