Happy Holidays CPASers, I have been wrapping my head around this problem. We recently ran some sequest data
using a new fasta file (attached). Peptide and protein prophet looked fine so then We uploaded the database and
didnt specify a species and chose not to guess one. We ran update seqId. We then uploaded our data and under
Grouping: None
Descriptions are listed for only some of the IPIs, there appears to be these blank spots where descriptions should be
this is also true under protein expanded(and collapsed).
It looks like
O08521_CRIGR 39,196 Peptides: 3 Unique: 1 O08521_CRIGR (O08521) Homologous to 40kD subunit of RNA-polymerase I and III (Fragment)
O08614_MOUSE Peptides: 1 Unique: 1
O08706_MOUSE Peptides: 1 Unique: 1
O08732_MESAU 26,926 Peptides: 1 Unique: 1 tr|O08732 Chymase 1 - Mesocricetus auratus (Golden hamster).
So I purged those MS runs and deleted the protein database, I reloaded the db but this time I told it to
guess the organism. We ran update seqId and then Reloaded the data and had the same problem.
If you click on an protein link that has no description, like O08614_MOUSE above you receive:
500: Unexpected server error
under show more details
The error shows:
ERROR Table 2006-12-27 11:22:27,695 8080-Processor21 : SQL Exception
org.postgresql.util.PSQLException: ERROR: table "containerlinkstemp" does not exist
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1525)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1309)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:188)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:340)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:332)
at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.execute(DelegatingStatement.java:261)
at org.fhcrc.cpas.data.Table.execute(Table.java:108)
I spotted that this is bug currently being fixed in a future release. I ran the new
Database Consistency Checker program and it showed the following:
Checking PropertyDescriptor consistency..
Checking DomainDescriptor consistency..
Checking Container Column Refernces..
ERROR: ms2.proteinprophetfiles rowid = 141 Container: 83fe5a56-39e7-1029-b852-d5bc503df33b
ERROR: ms2.runs run = 152 Container: 83fe5a56-39e7-1029-b852-d5bc503df33b
-- Following are suggested SQL commands to delete the orphaned rows found.
These commands must be run manually through a SQL tool and may not be in the correct order.
DELETE FROM ms2.proteinprophetfiles WHERE Container = '83fe5a56-39e7-1029-b852-d5bc503df33b' ;
DELETE FROM ms2.runs WHERE Container = '83fe5a56-39e7-1029-b852-d5bc503df33b' ;
Checking Schema consistency with tableXML..
Database Consistency checker complete
So I went onto my pdAdmin Query window and attempted the delete commands suggested:
I recieved the following error:
ERROR: update or delete on "proteinprophetfiles" violates foreign key constraint "fk_ms2proteingroup_ms2proteinprophetfileid" on "proteingroups"
DETAIL: Key (rowid)=(141) is still referenced from table "proteingroups".
Before I alter the table which I will have to do to drop the foreign key and do something like
alter ms2.proteingroups drop constraint fk_ms2proteingroup_ms2proteinprophetfileid FROM ms2.proteingroups WHERE rowid =141;
I thought I would post since I dont know the database design of cpas. and I'm not sure is this is the root of the problem I'm
having.
Anyone had this problem before? We just upgraded to CPAS 1.7
Any advice folks have would be great. thanks -Rich |
| |
| adam responded: |
2007-01-03 12:01 |
It's difficult to diagnose this problem (or problems) without having access to your system. Best guess: the fundamental problem is caused by mismatched FASTA files. O08614_MOUSE and O08706_MOUSE appear to have NULL SeqIds, which would happen if you used one version of your FASTA file for the search (e.g., the file you attached) but loaded a different version into CPAS (one without O08614_MOUSE and O08706_MOUSE entries). Another clue that seems to indicate out-of-sync FASTA files: the description you're seeing for O08732_MESAU is NOT the description in the FASTA file you attached. The showRun page will show the full path to the FASTA file CPAS loaded, so you should diff the file in that location against the attached file.
You stated above that clicking on one of the links results in a "table 'containerlinkstemp' does not exist" error -- is that really true? This error may get logged & displayed when using the Database Consistency Checker, but it has nothing to do with NULL SeqIds. I would expect you'd receive a ConversionException when clicking one of those protein names; clicking the protein name in the peptide view should result in a "protein sequence not available" error.
You shouldn't need to use "Update SeqIds" on recently loaded FASTA files. If you have FASTA files with duplicate sequences that were loaded with CPAS 1.3 or earlier they could result in NULL SeqIds; this button fixes those loads. You can check for NULL SeqIds with this query: SELECT * FROM prot.fastasequences WHERE SeqId IS NULL
As mentioned in another post, you should just let CPAS load the FASTA file when results are loaded; no need to load FASTA files manually or mess with organism guessing.
If you're seeing the "containerlinkstemp" error when running the db checker just ignore it -- it's totally benign.
I wouldn't worry about the orphaned Run and ProteinProphetFile entries either; these aren't causing any harm.
Adam |
| |
| Peter responded: |
2007-01-03 13:48 |
I am now working on the database consistency checker to get rid of the container links temp error message and improve the output messages. I agree with Adam, I can't see a way that this error message could result from any action other than running the checker. As for the cleanup via deletes, the problem is that the script needs to include deletes of the rows that depend on either the protein prophet fileid or the run id. If you want to cleanup the database, you wouldn't want to drop the constraint itself, just delete the rows that are dependent on the container that is missing. It is probably a good idea to ignore those orphaned rows for now as adam suggests. |
| |
| adam responded: |
2007-01-04 09:56 |
| Assigned To: adam |
|
| |
| adam responded: |
2007-02-07 11:18 |
This support request is being closed because it appears to be resolved. If you disagree, post a response and set the status back to Active. |
| |
|
|