cancel
Showing results for 
Search instead for 
Did you mean: 

Problem moving Enterprise 3.1 from one machine to another

iblanco
Confirmed Champ
Confirmed Champ
We want to move an Alfresco Enterprise Installation from one machine to another.

We have stopped Alfresco, dumped the database to a new database, copied de alf_data directory to another place, configured tomcat and started tomcat in the new machine.

As soon as it boots alfresco tries to upgrade the schema starting to "upgrade to 2.2" which obviously is a nonsense. Does anyone undertstand why ?

The old machine was running tomcat5.5 and this one is running tomca6 but I think the configuration is correct because if I start tomcat6 with an empty DB and empty alf_data it just creates everything from scratch and works.

I've trie disabling patches just by empty-ing the patch lists in bootstrap-context.xml but it seems as if there were still some remaining patches somewhere.
4 REPLIES 4

iblanco
Confirmed Champ
Confirmed Champ
I've tried with tomcat5.5 and the problem remains. The used JDK is also different but I don't think this could be the reason.
Any help would be much apreciated.

mrogers
Star Contributor
Star Contributor
If it is running patches then there is a mismatch between the code and the database.

Is your configuration of the database correct?   And in particular if you are installing on a vanilla tomcat 6 have you set up the shared class loader to pick up your custom configuration.

iblanco
Confirmed Champ
Confirmed Champ
We are using a database dump and a alf_data copy made from the running site (while tomcat is stopped of course), so I doubt there is a mismatch in code an Database, but we will repeat the process just in case.

We are installing on Debian Squeeze's Tomcat6 package, not vanilla. But the shared class loader is running fine as we have some custom beans defined there as well as the database configuration and they are being correctly loaded (we have some logging on bean initialization), besides I can see the SQL sentences executing against the configured database (which has not the default password nor the default name).

iblanco
Confirmed Champ
Confirmed Champ
Forget it, MRogers you were completely right. After rechecking we noticed that we made a big mistake while dumping the DB, we were dumping an erroneus DB.

I'm very sorry for the inconvinience caused.