Solved, It was tables created during an earlier failed upgrade.
If I deleted the tables it worked.

Best wishes
Allan Lind-Thomsen

Hi Allan,

I'm glad you were able to complete the upgrade successfully, but sorry to hear about the problem. Can you attach the labkey.log file from your server? It may contain additional information about the root cause of the problem that got the server into the bad state.

Thanks,
Josh

Hi Josh

Thanks.

Here is the log-file.

The upgrade happend sept. 8. and 9.
Somewhere after this timepoint: 2015-09-08 11:39:05,943

Best wishes
Allan

Dear Josh

Have you learned anything? I ask because the problem reappered after adding an externalModule. I only added the config directory and the module.xml file, and then started the server. It seems like it also reinstall the ms2 module which gives the error.

Can it be something remaining from my previous issue that get stuck because I just removed the views by force?

Best wishes
Allan

Hi Allan,

Yes, if you've manually removed or created views in the database that could be contributing to the problem. Unfortunately the log file you posted earlier didn't have any additional insight.

Whenever a module is upgraded we drop all of the database views for all of the modules and recreate them in case there are dependencies that have changed.

If you can get your server to start up, you can go to this URL (swapping out the server and port as needed) to completely reset the database views:

http://localhost:8080/labkey/admin/recreateViews.view

To clear up the bad state, you might need to temporarily remove your external module, restart the server, recreate the views via the URL, shut down again, re-add your external module, and restart the server.

Thanks,
Josh

Hi Josh

Worked like a charm :-)

Thanks

Best wishes
Allan

Hi again

The problem resurfaced and I need to get it solved.

I did a clean install of labkey 15.2 (build:39349.20), with MS SQL Server. Everything was done with the same user
1. I started tomcat which created the database and a few tables.
2. I shutdown tomcat
3. installed GROUP_CONCAT
4. restarted tomcat
5. made a site admin user
6. shutdown tomcat
7. installed a module with only the config/module.xml file
8. restarted tomcat: got the error FastaAdmin already exists.
9: shut down tomcat
10: removed the module
11: restarted tomcat
12: ran: http://localhost:8080/labkey/admin/recreateViews.view
13: got the error again

I checked the the stored procedure core.fn_dropifexists and ran:

EXEC core.fn_dropifexists 'FastaAdmin', 'prot', 'VIEW', NULL

in management studio and it ran without problems, BUT it didn't delete the view and the return value is 0.
Even if I manually delete the view I can run http://localhost:8080/labkey/admin/recreateViews.view but if I run it again it fails. (all the other views are deleted without problems.)

It seems that core.fn_dropifexists doesn't work for FastaAdmin which must be a permission issue. I have compared FastaAdmin with ms2.spectra and they seem to have the same permissions set. Also the schemas ms2 and prot seems identical.

As I appear to be the only one having the problem I assume the problem is in the database or server config somehow.

But is there anything that is being created differently in the two schemas?

Do you have any idea about what is going on here? Any suggestions to what I can try to find the problem?


Last minute addition: I found that
select OBJECT_ID('prot.FastaAdmin') returns an id
while
select OBJECT_ID('prot.fastaadmin') don't

So it seems that the function is vase sensitive with respect to fastaadmin but not the views in ms2, is there any digferencein how these views and schemas are created?
 
Best wishes
Allan Lind-Thomsen

No difference in the creation steps of the ms2 objects vs. prot objects. You can inspect the SQL scripts in /schemas/dbscripts/sqlserver, in particular:

• ms2-0.00-12.20.sql
• ms2-create.sql
• ms2-drop.sql

I don't know why OBJECT_ID() would be case sensitive when referencing your prot schema. To investigate this further I suspect we would need direct access to that database.

Adam

Hi Adam and Josh

First of all I want to thank you all your help and support.
It turned out to be an issue with the danish collation. In danish we have a letter å which in the old days was written aa. The collation translate aa, Aa and AA to Å or å, but aA is not translated.
This means that aa != aA even when a case insensitive collation is used.
So if I change FastaAdmin to Fastaadmin in ms2-create.sql and ms2-drop.sql it works in the cases where I have had problems.
Do I need to change in other places as well??
You can check the following if you like to see the issue in action.
select 1 where 'FastaAdmin' like '%aA%' collate Danish_Norwegian_CI_AI
select 1 where 'FastaAdmin' like '%aa%' collate Danish_Norwegian_CI_AI

select 1 where 'FastAadmin' like '%Aa%' collate Danish_Norwegian_CI_AI
select 1 where 'FastAadmin' like '%aa%' collate Danish_Norwegian_CI_AI
Best wishes Allan

Hi Allan,

The FastaAdmin is only located within the MS2 modules, so I think you've covered it.

I've checked the code and couldn't find it listed anywhere else that wasn't tied to the MS2 module, so I think you should be good.

Please feel free to contact us if you have any further questions.

Regards,

Jon

Hi Allan,

We've made a change to the fn_dropifexists procedure to avoid this problem going forward. It will be part of version 15.3.

https://www.labkey.org/issues/home/Developer/issues/details.view?issueId=24474

Thanks,
Josh

Hi Jon and Josh

Sounds good :-)
Thanks a lot for your all your help.

Best wishes

Allan