in reply to DBI fails to return an error code
Are you by any chance the same person that posted on stackoverflow at http://stackoverflow.com/questions/7432944/undefined-dbierrstr-using-dbi-perl-and-mysql-on-windows-7-x64/7434259 and who posted to dbi-users mailing list at http://www.mail-archive.com/dbi-users@perl.org/msg34081.html and reported https://rt.cpan.org/Public/Bug/Display.html?id=71047?
If so I have tried to help on some of those forums but you need to come up with something demonstrable that anyone else can run. The problem is that every pseudocode version you've posted works fine for me so I can only assume a) you have different versions or b) I've misinterpreted your pseudocode.
Write a small self contained real example that fails, post it along with your Perl, DBD::mysql and DBI versions and show the exact output of the script which demonstrates $DBI::errstr is not defined. Then if we cannot reproduce it we can help you debug it or perhaps trace it but we need to see a real life full example.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: DBI fails to return an error code
by djten (Novice) on Oct 09, 2011 at 02:21 UTC | |
No, that was not me that created any of those other posts. Interesting though, it looks like that person is having the same issue. Actually, that person is having the reverse of my problem. It's my Windows 7 Pro SP1 (32bit) installation that has the DBI error values working as expected, and my Vista Home Premium SP2 laptop that is not. In any event, you raise a good point, I should have included some explicit examples along with my initial rambling. Keep in mind, however, this is not a matter of one isolated piece of code giving me trouble. On my Win7 desktop computer, all of the DBI error reporting works properly, everywhere throughout the entire project, and on my Vista laptop, all of the DBI reporting FAILS to work throughout the entire project. Here's some sample code. I will use the snippet I purposely messed up, that I referenced in my reply to the previous post.
The actual column is really named just Credits, not DCredits. I might not be handling the above code in the best way (feel free to let me know), but I want to catch any possible error at each point of preparation, and pass it to a subroutine db_err. It's actually a method in a little module I made for this project. The simple code for that is as follows.
Presenting any database errors that may occur in this way is one of the requirements of the project. To duplicate the data, here is a series of MySQL statements.
The versions I am using on both desktop and laptop: ActiveState Perl v5.12.4, Apache v2.2.17, MySQL v5.5.8, DBI v1.616, DBD::mysql v4.018. Using the above back in my project, I get the following on my Win7 desktop computer.
etc. for the other rows. Clearly passing on what the error was. On my Vista laptop, I get the following.
etc. No error information at all. | [reply] [d/l] [select] |
by mje (Curate) on Oct 10, 2011 at 08:20 UTC | |
I installed DBD::mysql 4.018 and DBI 1.616 and ran the following based on your posting (note I had to invent $planname and substitute $dbname. Also I took out the fetch as it cannot work:
It fails with:
When I rerun it with DBI_TRACE=15 I get the following near the end:
What does your trace output look like on the failing machine? | [reply] [d/l] [select] |
by djten (Novice) on Oct 25, 2011 at 18:23 UTC | |
I have come across a solution for this. Which I find a relief, because it means I wasn't really slipping even further into insanity. This time. The trace suggestion was a good one, even though the trace output on the two computers did not reveal anything definitive. The trace on my desktop computer showed the error being processed, and the trace on the laptop showed everything processing right through as if it was an error-free transaction. However, it did get me thinking about possible module bugs, since I had ruled out everything else I could think of. I noticed that ActivePerl package manager showed that there was already a new version of DBD::MySQL available (4.020). So I updated both computers to that version, and when I ran the identical code on both computers again, they both caught and reported the error successfully and identically. So my laptop will once again be useful when DB-related debugging is necessary. I noticed on CPAN, the DBD::MySQL bug report had some recent references to "Undefined $DBI::errstr," and the change log for v4.020 says "Numerous fixes for prepared statements," without much detail beyond that. At this point I am going to go forward on the assumption that this was some kind of DBD::MySQL bug, and with v4.020 installed I am good to go. Thank you to all who offered your wisdom to help with my problem. | [reply] |
by mje (Curate) on Nov 01, 2011 at 11:14 UTC | |