User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 1.0.3705) Build Identifier: Switched bugzilla to a new server and now get this error. This error was not present on the previous server. Reproducible: Always Steps to Reproduce: 1. 2. 3.
There was no upgrade. It was from 2.17.4 to 2.17.4 The database was dumped and then added to the new server. Mysql server version: 4.0.15-log
I can't reproduce this. Did this happen after you'd already tried and failed to run checksetup once? (I remember something about a wrong DBD version on irc). Can you still repro it on a fresh export/import/checksetup?
After upgrading to 2.17.5 error is now: [Mon Nov 3 03:15:54 2003] checksetup.pl: Can't use an undefined value as an ARRAY reference at ./checksetup.pl line 3505. I can't find the original backup file I used anymore so I'm not able to test that. Is there anything I can do to fix up my database so that this error will not happen?
Version: 2.17.4 → 2.17.5
http://miranda.nwcr.net/~kkemp/bugs_backup.tar.gz The current mysql backup.
3502 $sth = $dbh->prepare("SELECT fieldid FROM fielddefs " . 3503 "WHERE name='attachstatusdefs.name'"); 3504 $sth->execute(); 3505 my $old_field_id = $sth->fetchrow_arrayref()-> || 0; The problem, I believe, is that the query doesn't return any rows, so $sth- >fetchrow_arrayref() returns undef. If you do the select query above in mysql, what are the results it returns? Copying myk, I'm not familiar enough with the code in question to recommend a fix to your DB or to the code. I'll try to dig deeper. That section of code converts the old attachment statuses to flags.
Yeah, that's not returning any rows mysql> SELECT fieldid FROM fielddefs WHERE name='attachstatusdefs.name'; Empty set (0.00 sec)
The below is qualified by the fact that all I've been doing is reading code, not testing. It looks as though the first time you attempted to run checksetup, it managed to get through to line 3618: $dbh->do("DELETE FROM fielddefs WHERE name='attachstatusdefs.name'"); but it didn't run the drop table attachstatuses and drop table attachstatusdefs twenty lines above that. Do you still have the error on hand from when you attempted to run it with a version of DBD::mysql (I think) that was wonky? I'd like to know what line it crapped out on. You might try to drop the two tables (attachstatuses, attachstatusdefs) manually from the DB, and then run checksetup, and see what all happens. This will serve to avoid the problem block of code, but won't update attach statuses into flags if that has not already happened. You could also instead try changing the line: my $old_field_id = $sth->fetchrow_arrayref()-> || 0; into my $old_field_id = $sth->fetchrow_array() || 0; and see if that changes anything. That will stop the erroring. I -think- undef || 0 will put 0 into $old_field_id. If it doesn't, break it into two lines: my $old_field_id = $sth->fetchrow_array(); $old_field_id = 0 unless defined $old_field_id; I'll follow my own suggestions with the backup you provided when I get home.
Created attachment 134731 [details] [diff] [review] avoid error OK. I can verify that your DB does indeed cause this error. The attached patch gets rid of the error and allows checksetup to run. It still whines with the following warnings: [Mon Nov 3 19:45:50 2003] checksetup.pl: DBD::mysql::st execute failed: Unknown column 'product_id' in 'field list' at ./checksetup.pl line 3528. [Mon Nov 3 19:45:50 2003] checksetup.pl: DBD::mysql::st fetchrow_array failed: fetch() without execute() at ./checksetup.pl line 3529. In this case these errors are meaningless, because what was posted had no entries in the attachstatuses or attachstatusdefs table. A quick look around seemed to be that things were ok. Sanitycheck complained about this and that, but I don't know whether they were from before or after the transfer. Should be before, things like having open bugs with a resolution. Apply the patch, if you would, and try it out.
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: FreeBSD → All
Comment on attachment 134731 [details] [diff] [review] avoid error Yeah, we can't get into automatically fixing failures of checksetup. I don't want checksetup to just go along silently if something is messed up -- I want it to fail. So the error message that exists is correct. :-) The real problem would have been whatever caused his checksetup to fail in the first place, which is hopefully handled by now.
Attachment #134731 - Flags: review?(mkanat) → review-
We don't automatically fix past failures of checksetup, unless they were well-known failures in an official release. That's just an impossible can of worms to get in to.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Hardware: PC → All
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.