Labkey revision 29447 does not go through the upgrade stage

LabKey Support Forum (Inactive)
Labkey revision 29447 does not go through the upgrade stage Leo Dashevskiy  2013-11-13 12:37
Status: Closed
 
after a clean build I still get the following error:

500: Unexpected server error

A failure occurred during LabKey Server startup.

org.springframework.jdbc.BadSqlGrammarException: SqlExecutor.execute(); bad SQL grammar []; nested exception is org.postgresql.util.PSQLException: ERROR: constraint "fk_completiondates_employeeid" of relation "completiondates" does not exist
       at org.springframework.jdbc.support.SQLStateSQLExceptionTranslator.translate(SQLStateSQLExceptionTranslator.java:111)
       at org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.translate(SQLErrorCodeSQLExceptionTranslator.java:322)
       at org.labkey.api.data.ExceptionFramework$1.translate(ExceptionFramework.java:38)
       at org.labkey.api.data.ExceptionFramework$1.translate(ExceptionFramework.java:32)
       at org.labkey.api.data.SqlExecutor.execute(SqlExecutor.java:94)
       at org.labkey.api.data.SqlExecutor.execute(SqlExecutor.java:64)
       at org.labkey.api.data.SqlExecutor.execute(SqlExecutor.java:59)
       at org.labkey.api.data.SqlScriptExecutor$Block.execute(SqlScriptExecutor.java:168)
       at org.labkey.api.data.SqlScriptExecutor.execute(SqlScriptExecutor.java:64)
       at org.labkey.core.dialect.PostgreSql84Dialect.runSql(PostgreSql84Dialect.java:864)
       at org.labkey.core.dialect.PostgreSql90Dialect.runSql(PostgreSql90Dialect.java:29)
       at org.labkey.api.data.SqlScriptManager.runScript(SqlScriptManager.java:200)
       at org.labkey.api.data.SqlScriptRunner.runScripts(SqlScriptRunner.java:82)
       at org.labkey.api.module.DefaultModule.versionUpdate(DefaultModule.java:347)
       at org.labkey.api.module.ModuleUpgrader.upgrade(ModuleUpgrader.java:59)
       at org.labkey.api.module.ModuleUpgrader$1.run(ModuleUpgrader.java:75)
Caused by: org.postgresql.util.PSQLException: ERROR: constraint "fk_completiondates_employeeid" of relation "completiondates" does not exist
       at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2157)
       at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1886)
       at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255)
       at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:555)
       at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:403)
       at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:395)
       at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264)
       at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264)
       at org.labkey.api.data.dialect.StatementWrapper.execute(StatementWrapper.java:1015)
       at org.labkey.api.data.SqlExecutor$NormalStatementExecutor.execute(SqlExecutor.java:121)
       at org.labkey.api.data.SqlExecutor$NormalStatementExecutor.execute(SqlExecutor.java:109)
       at org.labkey.api.data.SqlExecutor.execute(SqlExecutor.java:89)
       ... 11 more

Thanks.
 
 
Ben Bimber responded:  2013-11-13 12:49
Hi Leo,

I believe that error is related to a fairly old SQL update script from one of our modules, which your local instance must be running. That constraint should have been created by EHR_ComplianceDB-0.00-11.20.sql, and later dropped in EHR_ComplianceDB-12.34-12.35.sql. I assume that's the script that's failing. I'm not sure why your instance would be in this state, but it sounds like that constraint was never created. I think there are a couple options:

1) Completely remove the EHR_ComplianceDB module from your local server. This would allow the server to start, since it would no longer try to run that SQL upgrade script. If you do this, once the server starts I would recommend going to the admin console, clicking on the 'Module Details' link (near Module Information). From this page, find EHR_ComplianceDB and pick the 'delete module and schema' option. This will drop that module, schema, and the other installation-related information stored in your DB. This means should you ever encounter that module again (like the next time you update from trunk), it should do a clean install, which is running normally.

2) If this is a dev machine, you could go into PG Admin and manually create that constraint along with any other missing SQL that was not run. This is sort of a hack and I would only ever try this on a dev machine. I also hesitate to try to go this route, since it might take some knowledge of the SQL upgrade scripts. I think the option above would be simpler and less prone to error.

-Ben
 
Leo Dashevskiy responded:  2013-11-13 13:12
Thanks, Ben!

First approach worked like a charm.

EHR_ComplianceDB is in the 'Unknown Modules' list under 'Module Details' down at the bottom.

Besides it there is about a dozen more modules in the 'Unknown Modules' list.

Should I obliterate them all too?

-Leo
 
Ben Bimber responded:  2013-11-13 13:13
That section is telling you about modules that at some point were installed, but are no longer present. I doubt it really matters one way or the other about force-deleting them.
 
Leo Dashevskiy responded:  2013-11-13 13:16
All good.