Enterprise Administration > File Vaulting and Replication > File Vaulting > Understanding File Vaulting > Diagnostic and Repair Tools > Detecting and Resolving Multiple Primary Content Files
  
Detecting and Resolving Multiple Primary Content Files
The WMultiPrimaryDetect command line utility detects and corrects a data issue where multiple primary content files have been associated with one FormatContentHolder object. WMultiPrimaryDetect is run from the Windchill shell with the command windchill wt.fv.tools.WMultiPrimaryDetect, passing suitable parameters as required. If no parameters are supplied, the tool runs in the diagnosis mode.
Running this tool in the default mode outputs an XML file, multiPrimaryDiagnosis_<YYYYMMDD_HHMM>.xml, which lists all of the incorrect FormatContentHolders and their multiple primary content items. The tool requires that a Windchill method server instance is up and running.
Following are the arguments you can use and their descriptions:
Argument
Description
-user=<adminid>
User ID of the administrator user.
-password=<adminpassword>
Password of the administrator user.
-fix
Operate in repair mode. If you use this argument, you must also specify the -inputFile parameter. If any content files are deleted, a copy of the content file is made in the <WT_HOME>/logs/ContentItems directory.
* 
The content files in vaults are not deleted; only the entries for them in the database are deleted.
-inputFile=<input full path and filename>
Use the specified XML file to delete primary content items. The XML file used as an input is the same XML file which was generated by running the tool in the diagnosis mode (which is the default mode). You must update the diagnostic file to change a value of the deleteThisItem field to Y for the content items whose database entries are to be deleted.
* 
The content files in vaults are not deleted, only the entries for them in the database are deleted.
-outputPath=<output pathname>
Use the directory path specified in outputPath parameter to save the XML output files.
* 
By default, a file with the name of the timestamp of the log is created within the <WT_HOME>/logs directory and the XML file is saved there. If this argument is specified and a path is supplied, the specified path will be used instead.
-confirmBeforeDelete=<Y/N>
Ask user for confirmation before deleting each file. The default value is Y.
-usage
Print list of valid arguments and then exit.
To operate in repair mode, this utility requires an input file that specifies files which are to be deleted. The XML file used as an input is the same XML file which has been generated by running the tool in the diagnosis mode (which is the default mode), but which you have updated to change the value of the deleteThisItem field to Y for the content items that are to be deleted.
* 
Modifying the XML file in any other manner may lead to inconsistent results.
Also, note that at least one primary content item per ContentHolder must exist. If all of the content items for a ContentHolder have been marked for deletion in the XML file, the tool will print an error message (in an errorMessage field in the XML file) for all content items for that ContentHolder, not delete any of them, and continue processing the rest of the XML file. The errorMessage field is optional and not present for objects that were successfully deleted.
When you run the tool in repair mode, a results XML file is generated which is stored in the same directory as the input file. The file name is formatted in the following way: multiPrimaryResults_<YYYYMMDD_HHMM>.xml. The format of this XML file is very similar to the multiPrimaryDiagnosis report, except that the deleteThisItem field is replaced with an itemDeleted field. This field has a value Y for content items that were deleted.
A copy of the deleted content file is saved as the original file name. If there is more than one file with the same name, a numbered suffix, such as _1, _2, and so on, is added. The saved name is also stored in the multiPrimaryResults XML file.
* 
In the WMultiPrimaryDetect tool, logging is controlled by the wt.fv.verbose setting in wt.properties. If this property is set to true, the tool provides verbose output.