Hi Aaron:

Sorry the upgrade didn't go smoothly. I suspect this is related to the increased checking for unknown modules that we added in 23.3. That unique constraint on module names ("uq_modulename") was added to catch potential issues, so sounds like either you have two modules with the same name or the server thinks you do. On a running server, you can see such unknown modules at the bottom of the module-details page, though if your server isn't starting up, you won't be able to see that page of course.

You should see the rest of the stack trace when you get that error, and it should include the name of the module violating the constraint. The full stack should be in the logs if not directly in the UI where you see the message. Does that help you identify what may have changed? If you see the name of a module that exists but has different casing (for example), try changing the casing to match. If it's a module that you used previously and dropped, try restoring it if possible (with the same name and casing) and see if that resolves this issue. Be aware with this latter option, of course, that module schemas can only be upgraded to 23.3 if they were previously on 22.1 (or later). Details are in our upgrade support policy.

If you need further assistance, please attach the full stack trace or log file, and tell us what version you were upgrading from, so that we can get a better idea of what might be going on.

Thank you for reaching out,

--Molly

Hello Molly,

Thank you for the quick reply. The version we upgraded from was 22.7.0. I have attached the original error in full, and the most recent error also. We didn't find any duplicate modules, even ones with differing cases. However, I removed the module it was complaining about in the original error (helloworld) and now that it is gone we get a SQL error. Any ideas?

Thanks!

Thanks Aaron, that's helpful.

Glad the duplicate module issue is resolved, and that makes sense as it's a frequently used 'test' module name.

That new error is unrelated, but one we know about and have fixed in our next maintenance release (23.3.3). Learn more in the internal issue here.

As mentioned there, this is only an issue when your upgrade of the compliance module skips the 22.11 release. You may be able to work around this one by first upgrading to 22.11.9 and then 23.3.2.

--Molly

Hello again,

I have downgraded to 22.11.0, my apologies, I did not realize I needed to upgrade in increments. Now, I am getting a java class error maybe (attached)? Any thoughts on this one?

Thanks

Based on how you phrased that, it's important to note that you can't downgrade a database to an earlier version, i.e. once you've upgraded to 23.3, you can't go back to 22.11. You'd have to roll back to the 22.7 version (i.e. restore it from backup) and upgrade that first to 22.11 and then to 23.3.
If that's what you did, are you seeing this on 22.11.9? Are there other errors in the logs or during startup?

Welp, I did indeed downgrade to 2.11 and the SQL error is gone. I'm getting a java cast class bootstrap error now. As for restoring from backup, I can do that for the application server, labkey itself. However, it's a long story but there is no backup of the database server, that's one reason I am trying so hard to fix it. I have attached what I get in the log file when I start up tomcat, maybe that will show something helpful. I really appreciate all of your help on this. Thanks!