Added debug statements to both those functions and they returned no values.
Versions: DBI 1.50 DBD:mysql 3.0002 -----Original Message----- From: Kristis Makris [mailto:[EMAIL PROTECTED] Sent: Thursday, April 19, 2007 11:14 AM To: Day, Tony Cc: [email protected] Subject: RE: [scmbug-users] Bugzilla Not Being Updated Hi Tony, you sound very frustrated. Ahhhh computers!! On Thu, 2007-04-19 at 10:00 -0600, Day, Tony wrote: > its very difficult for my to discern what is going on. I tried using > this to debug that I got from one of your interactions from a user in a > past e-mail, > > open OUTFILE, "> C://output.txt"; > print OUTFILE Dumper($self->username ( $data->{ database_username } ) ); > close OUTFILE; That's great. > But this only works for certain conventions within the scripts and I > don't know enough to tweak it to work in other parts of the script. I'm not sure what you mean by this statement. What do you mean "for certain conventions" ? > Incidentally, I put the above in the Bugtracker and Bugzilla.pm files > and they returned the expected value. My suspicion is that Bugzilla if > for some reason denying the attempted connection. Well, for example in integration_add_comment, in: } elsif ( $self->is_version_up_to_2_22() || $self->is_version_latest() ) { # AppendComment was fixed in Bugzilla 2.22. Should use the # native version my $userid = Bugzilla::User::login_to_id( $username ); ## Right here the $userid should be a valid user id. Definitely ## NOT ''. If you got a valid id here, then the database was ## contacted open OUTFILE, "> C://output.txt"; print OUTFILE "the userid is: " . Dumper($userid); close OUTFILE; } > If you could tell me how to verify that I guess we would, at least, know > where this is dying. But I don't know enough right now to figure out > how to do that. In general, follow the example above. Wherever you see that Bugzilla is being contacted, or an SQL statement is issued, try to add a debugging statement that shows what was received back. Here's another example for the product name, which should be retrieved and validated: sub integration_get_product_name { my $self = shift; my $bugid = shift; my $bug_product_name; my $sql; if ( $self->is_version_up_to_2_16() ) { $sql = "SELECT product FROM bugs WHERE bug_id = $bugid"; } elsif ( $self->is_version_up_to_2_18() || $self->is_version_up_to_2_20() || $self->is_version_up_to_2_22() || $self->is_version_latest() ) { $sql = "SELECT products.name FROM products, bugs WHERE bugs.bug_id = $bugid and bugs.product_id = products.id"; } PushGlobalSQLState(); SendSQL( $sql ); $bug_product_name = FetchOneColumn(); PopGlobalSQLState(); ## right here, try to print the $bug_product_name open OUTFILE, "> C://output.txt"; print OUTFILE "bug_product_name is: " . Dumper($bug_product_name); close OUTFILE; return $bug_product_name; } Could you try adding debugging statements in these two functions (integration_add_comment and integration_get_product_name) ? It should be easy to see if the database is contacted or not. If it's not, we are probably looking at a DBI or DBD::mysql issue. > I sent my config files to the group yesterday and didn't get any > feedback which tells me that there is nothing glaringly wrong in them. > So, I am gonna have to spend sometime building up my Perl scripting > skills before I can move forward with SCMBug implementation. I'm pretty sure that you only need to add some debugging statements like the one you are already using in order to get a good idea of what's going on, what's crashing, etc. You shouldn't need to learn Perl in all its glory. > If there is any additional assistance you can provide with respect to > tracking down the problem I would appreciate it. If not, I understand > as it is just as much my ignorance of Perl that is preventing me from > moving forward with this initiative. It's certanly not Perl ignorance. There's something in your environment we haven't figured out yet. Some more things to try: - Which version of the DBI are you using ? It should be at least > 1.50. 1.49 does not work: http://bugzilla.mkgnu.net/show_bug.cgi?id=646#c12 http://bugzilla.mkgnu.net/show_bug.cgi?id=646#c4 We are pretty sure 1.50 is needed: http://bugzilla.mkgnu.net/show_bug.cgi?id=646#c16 http://bugzilla.mkgnu.net/show_bug.cgi?id=646#c9 Perhays there's an issue with DBD::mysql too. Could you try upgrading these two modules to their latest versions ? ++++++++++++++++++++++++++++++++++= **** Could you please report the versions of DBD::mysql **** and DBI you are running ? ++++++++++++++++++++++++++++++++++= You should be able to find the versions by browsing/searching in c:\Perl \some\where - There is another alternative: To use cygwin's Perl and DBI. Aleksey documented this and has been running Scmbug under Cygwin for a long time now: http://bugzilla.mkgnu.net/show_bug.cgi?id=646#c5 If upgrading DBD::mysql and DBI did not help, try under cygwin. Scmbug under cygwin certainly works. Perhaps we won't find what the problem was in your setup (I really hope we do find it, and document it) but at least we'll get you going. Take a break, and try again ?! _______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
