G'day Bob,I successfully migrated from 1.2.1 through 2.0 and on to 2.3 although it was a pretty small database of around 100MB. That test "migration" also involved moving from postgresql 8.1 up to 9.1 as well. I strongly recommend http://phppgadmin.sourceforge.net/doku.php as a development and management tool for postgresql ;)
Paul... ----- Original Message ----- From: [email protected] To: [email protected] Cc: [email protected] At: Nov 1 2013 02:28:45 I’m not sure why jumping from 2.0.0 to 2.3.0 would fail. I think Paul Guttmann even did this recently. Michael, this problem is because you have some inconsistent data. You have a copyright record that points to a “pfile” record and that pfile record does not exist. What libschema.php is trying to do is add a database constraint to prevent this from happening in the future. Unfortunately, since it has already happened to you, you need a fix. BTW, this situation may have occurred in the past due to an error deleting an upload. The current delete agent is much more robust. One solution is to delete all your copyright records. However we can be a little more surgical and just delete the bad ones. For example, in psql (or wherever you wish): 1) create view copyright_pfile as select ct_pk,pfile_fk,pfile_pk from copyright right outer join pfile on pfile_fk=pfile_pk; 2) delete from copyright where ct_pk in (select ct_pk from copyright_pfile where pfile_fk != pfile_pk); 3) drop view copyright_pfile; Yes, you can do all the above in a single delete statement if you wish. I just broke it up because I think it is easier to understand. Bob Gobeille On Oct 31, 2013, at 10:45 PM, Michael Silberman <[email protected]> wrote: Unfortunately the yum install worked at least to change the revision, but not the DB. The script shows errors: PHP Warning: pg_query(): Query failed: ERROR: insert or update on table "copyright" violates foreign key constraint "copyright_pfile_fk_fkey" DETAIL: Key (pfile_fk)=(55328) is not present in table "pfile". in /usr/share/fossology/lib/php/libschema.php on line 456 <hr>File: /usr/share/fossology/lib/php/libschema.php, Line number: 457<br>ERROR: insert or update on table "copyright" violates foreign key constraint "copyright_pfile_fk_fkey" DETAIL: Key (pfile_fk)=(55328) is not present in table "pfile".<br> ALTER TABLE "copyright" ADD CONSTRAINT "copyright_pfile_fk_fkey" FOREIGN KEY ("pfile_fk") REFERENCES "pfile" ("pfile_pk") ON UPDATE NO ACTION ON DELETE CASCADE;<pre>#0 debugbacktrace() called at [/usr/share/fossology/lib/php/common-db.php:158] #1 DBCheckResult(, ALTER TABLE "copyright" ADD CONSTRAINT "copyright_pfile_fk_fkey" FOREIGN KEY ("pfile_fk") REFERENCES "pfile" ("pfile_pk") ON UPDATE NO ACTION ON DELETE CASCADE;, /usr/share/fossology/lib/php/libschema.php, 457) called at [/usr/share/fossology/lib/php/libschema.php:457] #2 ApplySchema(/usr/share/fossology/www/ui/core-schema.dat, , fossology) called at [/usr/lib/fossology/fossinit.php:102] Is there anything I can do to fix it? From: Ma, Dong (Vincent, Open Source Program Office) [mailto:[email protected]] Sent: Thursday, October 31, 2013 8:00 PM To: Michael Silberman; [email protected] Subject: RE: Post Upgrade to 2.3.0 Problems Hi, We suggest upgrade packages from previous latest release packages, I am sorry we didn’t test from 2.0.0 upgraded to 2.3.0 (over 2 releases: 2.1.0 and 2.2.0) . The error message show your DB upgrade not successful, 1. I suggest you first check if the 2.3.0 packages install correctly, use ‘rpm –qa|grep fossology’ to check fossology version 2. If the 2.3.0 packages already installed, run the post install script again, ‘/usr/lib/fossology/fo-postinstall ‘, check if any errors Hope the post install script can fix it. If you catch any errors, please forward to us. Thanks, Vincent From:[email protected] [mailto:[email protected]] On Behalf Of Michael Silberman Sent: 2013年11月1日 6:51 To: [email protected] Subject: [FOSSology] Post Upgrade to 2.3.0 Problems Hello, After upgrading from 2.0.0 to 2.3.0 on RHEL6.3 using “yum upgrade fossology*” per the instructions I’m seeing some errors that would indicate that something went wrong with the DB upgrade portion. Unfortunately I didn’t think to redirect the upgrade output to a log file. <image001.jpg> Is there any way to resolve this quickly? Regards, Michael Silberman Sr. Systems Administrator [email protected] 1(408)890-3521 <image002.jpg> This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately _______________________________________________ fossology mailing list [email protected] http://lists.fossology.org/mailman/listinfo/fossology
6528107167258002.txt
Description: Binary data
_______________________________________________ fossology mailing list [email protected] http://lists.fossology.org/mailman/listinfo/fossology
