Migrated server project issue

Post Reply
Kevin Campbell
Posts: 40
Joined: 13 Sep 2010, 20:26

I am testing the process of migrating our Protege server to a different machine. Source and target machines both have a localhost SQLServer with identically named databases and user IDs.

I've moved the 3 files associated with the project and used SQLServer utilities to migrate the entries in the table.

Upon opening the project the Protege log window shows a number of issues encountered with some fairly basic slots:

WARNING: Wrong type: Slot(attribute_value) -- DefaultKnowledgeBase.getFrameOfType()
WARNING: Unknown class: Attribute_Value -- Project.loadWidgetDescriptors()
WARNING: Wrong type: Slot(technology_component_architecture) -- DefaultKnowledge
Base.getFrameOfType()
WARNING: Unknown class: Technology_Component_Architecture -- Project.loadWidgetDescriptors()

(A few more entries follow)

I don't know anything about the internal data representation format used by Protege, but the number of source and target rows is the same. Examining rows where short-value = 'attribute_value' shows precisely the same 12 rows in each database. When looking at the slot definitions I see that indeed the slots and classes mentioned are not in the copied project, but are in the source.

Any suggestions?

Kevin
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

That's a tricky one.

I have moved projects about that use a database backend without a problem in the past.

If you're using a database backend, the only files you need to move are the .PPRJ file (this is the Project file that tells Protege about your repository) and the database file (which contains the repository).

You will also need to move the metaproject.[pprj, pins, pont] which control your Protege server configuration.
In the metaproject, make sure that the entry for your repository is pointing to the right location for the PPRJ that I mentioned above.
From what you describe, however, it sounds like you have all this in order.

Questions:
- How did you 'move' the database file?
- Did you perform a database backup and then a restore?

I have always used the approach of taking a backup of the source database and then restoring that backup into the target.

The internal representation that Protege uses in the database is pretty simple by VERY normalised and extremely difficult to reverse-engineer. So much of it is references to references and if something is only slightly out of whack...

Let me know about how you moved the DB and we can take it from there.

Jonathan
Essential Project Team
Kevin Campbell
Posts: 40
Joined: 13 Sep 2010, 20:26

We're thinking along the same lines - I have a suspicion that something subtle in the representation of the data got lost in translation. I used SQL Server "Import and Export Data" tools to basically stream the data from one server to another.

We've just repeated the exercise using a backup from a couple of weeks ago without issue, we're going to try that again with the most current backup.

Kevin
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Yes, that's what I would recommend.
The Backup / Restore creates a bunch of SQL commands and is all text based, so seems to be quite robust and reliable.

Let me know if this resolves the issue

Thanks

Jonathan
Essential Project Team
Kevin Campbell
Posts: 40
Joined: 13 Sep 2010, 20:26

Looks like it is indeed an issue associated with the delivered SQL Server utilities, when used to copy data directly from one database to another. Restoring from a backup works correctly.

Kevin
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Thanks for posting back and sharing this, Kevin.

It's very valuable to know things like this!

Jonathan
Essential Project Team
Post Reply