Problem moving Enterprise 3.1 from one machine to another
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-09-2010 02:05 PM
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.
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.
Labels:
- Labels:
-
Archive
4 REPLIES 4
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-09-2010 02:29 PM
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.
Any help would be much apreciated.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-09-2010 03:09 PM
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.
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.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-10-2010 02:27 AM
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).
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).
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-10-2010 02:37 AM
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.
I'm very sorry for the inconvinience caused.
