…Old version 0.1 of metadata schema detected; migration to version 0.2 required

I ran repair (for lack of a better idea) from the Web folder with the following abbreviated results:

Metadata has been migrated to version 0.2
Unable to repair

The collection that is WebDAV enabled contains a single TSD3 schema. Can someone straighten out this WebDAV newbie? What does this mean? Thanks.

Tamino v3.1.2.1
WebDAV v3.1.4
Apache v1.3.26
W2K Pro


the technical background is: you already had a webDAV enabled collection onyour computer created with an older version of Tamino WebDAV Server. With version 3.1.4 the schema for the metadata changed. This is indicated with the ServiceInitializationError.
After a repair and a restart of TWS should now be visible. If you still get the ServiceInitializationError, start the repairer from the console (Start Menu/programs/Tamino WebDAV Server/Console) with command:

inodavrepair -allStores


Hi Steve,

could you please send:

a) the repair log file (%installdir%\taminowebdavserver\repairer<the-name-of-your-store> )

b) the server log files localhost_log..txt and nt_service_jvm_stdout.log (%installdir%\jakarta-tomcat\logs)


Martin, I ran the repair on all stores with the following results…

Error: com.softwareag.tamino.db.API.accessor.TDefineException: NestedException:Tamino access failure (INOXSE8944: Object definition missing in the new schema definition., Line 3, Column 2: Element name = shadow )
Cause: NestedException:Tamino access failure (INOXSE8944: Object definition missing in the new schema definition., Line 3, Column 2: Element name = shadow )
Result: Unable to repair

Peter, I have included the logs for the repair run on the single collection only.

I also must correct the statement regarding a single TSD3 schema within the collection. There are multiple TSD3 schemas defined with the WebDAV enabled collection.

Thanks to both of you. (4.68 KB)


sorry for late reply - we are about to do the final handover of the next version of TWS which, btw will be available in 3-4 weeks. In that version we have definitly enhanced stability and quality of the product.

I got the log files, thank you. Unfortunately we could not take any conslusions from it. So, as a next step I will try to reproduce the problem myself by first creating some data (at least 2 doctypes) using TWS 3131, than upgrade to 3145 and see what happens.



I could not reproduced your problem. Although the schema language (TSD2 or TSD3) of the content data shouldn’t care (because repair in TWS only accesses the metadata), I forced the usage of TSD3.

Here is what I did (my Tamino is version

1) installed TWS
2) created dummy TSD3 schema in collection “mycoll”
3) configured store “mycoll” and to access collection “mycoll”
4) created some docs in store “mycoll” (2 additional schemas are created by means of config parameter “autoCreateXmlSchema”)
5) installed TWS (uninstall of is triggered by the setup)
6) as my config file was rescued at %temp%, I can takeover my previous config by means of the following command in the TWS comsole:
inodavstores takeover -fromDomainFile “%temp%\Domain.xml”
7) restart TWS
8) using WebFolders, verify that store “mycoll” is unavailable (ServiceInitializationFailedException.xml)
9) started repair by copying /taminowebdavserver/administration/etc/StartRepairer.xml to the location /taminowebdavserver/administration/repairer/mycoll
10) wait till the repair log file is there

I attach in return my logs.

Some hints:
- did you try starting repair from the WebDAV interface as I did (by copying StartRepairer.xml) instead of using the console command? Maybe it’s easier and less error-prone
- while repair was running, did you maybe access the DB using X-Plorer? … it could block the repair process

Peter (1.72 KB)