Since the database has lost consistency, I'd really try a fresh pg_dump / import if that's possible.  If there's an error this time around, note it and send it on over and we can figure out where to go from there.


On Tue, May 27, 2014 at 11:48 AM, Paniagua, Eric <epaniagu@cshl.edu> wrote:
The "dataset" table is populated.  I looked at the SQL dump file I used to copy the database, and it has create table and copy into statements for history_dataset_association, but it looks like there may have been an error while executing them.  Trying to figure out how to get  my data in...
________________________________
From: Dannon Baker [dannon.baker@gmail.com]
Sent: Tuesday, May 27, 2014 11:43 AM
To: Paniagua, Eric
Cc: galaxy-dev@lists.bx.psu.edu
Subject: Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host

On Tue, May 27, 2014 at 11:26 AM, Paniagua, Eric <epaniagu@cshl.edu<mailto:epaniagu@cshl.edu>> wrote:
Thanks for pointing that out!  I missed it.  I am now connecting to the remote database.  I ran "sh manage_db.sh upgrade" and it upgraded from schema 114 to 118 without error messages.  I then ran "sh ./scripts/migrate_tools/0010_tools.sh install_dependencies" and received the following error:

line 35, in __getitem__ return self.data_tables.__getitem__( key ) KeyError: 'gatk_picard_indexes'

I fixed this by adding the appropriate entries to tool_data_table_conf.xml.  I then reran the migrate_tools command successfully.  However, now my "history_dataset_association" table in the database was blown away at some point.  The table is now completely empty.  Have you ever seen this before?

I have not seen the tool migration issue before, but it seems harmless.  The fact that your history_dataset_association table is empty is concerning if there was ever anything in it.  Can you verify that there are datasets in the same database that *should* be associated to a history?  It sounds like this galaxy instance has been used with different databases, and my hope is that the wires are crossed up here and there actually should not be any.