Community
Vault Forum
Welcome to Autodesk’s Vault Forums. Share your knowledge, ask questions, and explore popular Vault topics.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Reference Repair Utility - error occurred while attempting to retrieve a file

8 REPLIES 8
SOLVED
Reply
Message 1 of 9
mthomas
2153 Views, 8 Replies

Reference Repair Utility - error occurred while attempting to retrieve a file

I'm working thru the 4-part procedure in the Autodesk wiki on using the Reference Repair Utility. I've successfully exported the .xml file and edited it to fix the references. Now when I attempt to import the file to update the relationships on the server I get the message "An error occured while attempting to retrieve a file" and the process stops.

 

The console log shows... any ideas?

 

1/8/2013 8:00:20 AM  
1/8/2013 8:00:20 AM -Oimportreferencetable -N"PMP" -FIN"t:\transfer\PMPW2k8v1_PMP_2012-12-14-08-32.xml" -VU[username] -VP[password] 
1/8/2013 8:00:22 AM An error occurred while attempting to retrieve a file.
1/8/2013 8:00:22 AM Connectivity.Application.VaultManager.ServiceException: GetFileFailed [1013]  ---> Connectivity.Document.Util.DocumentException: GetFileFailed [1013] 
Mike Thomas

8 REPLIES 8
Message 2 of 9
minkd
in reply to: mthomas

There is a problem in the import that occurs when either the Parent_Missing_Ref path is found in the vault but the Parent_Version is not, or the Matching_Ref_In_Vault path is found but the Ref_Version is not.  Either of these conditions was supposed to issue a warning and continue, but instead it is a fatal error. It was not deemed important enough to hold up the service pack.

 

The solution is to make sure the version number is valid for both the parent and child.

 

-Dave



Dave Mink
Fusion Lifecycle
Autodesk, Inc.
Message 3 of 9
mthomas
in reply to: minkd

I went in and changed all the children versions to 1 as a test and it imported without error. What a pain this is, but at least now it is working

 

Thanks

 

Mike

Mike Thomas

Message 4 of 9
andrew_buc
in reply to: mthomas


@mthomas wrote:

I went in and changed all the children versions to 1 as a test and it imported without error. What a pain this is, but at least now it is working

 

Thanks

 

Mike


Does this mean that parent files will now be linked to version 1 of the child file, even if they were previously linked to a newer version? If so, I agree with your "what a pain" sentiment. Is there a fix for this once you've imported the .xml?

Message 5 of 9
minkd
in reply to: andrew_buc

The reference repair utility does its best to find a good version to use. However, if you do a purge before importing corrected references or change the suggested version number before importing, then it is possible that particular version will not exist and you will get this error when you try to import.

 

If you need to fix it after importing, you can reset the references for a particular parent file (which deletes any imported references), and then you can correct the XML and re-import.

 

-Dave

 



Dave Mink
Fusion Lifecycle
Autodesk, Inc.
Message 6 of 9
B.Rawling
in reply to: mthomas

Dave

Can you confirm the following 

 

You said

If you need to fix it after importing, you can reset the references

 

we are using Vault Collaboration 2012(Update 3)

First question regarding your statement above....

To reset the references do you simply remove the TRUE entry in the Xml and re-import.

If not what is the correct method to reset the references after importing?

 

Second Question

Can you test the import to fix the references on a second vault  server if it is built from a full vault restore of the original live Vault

I take it the Vault server name may need to be changed in the Xml, is this possible and is there anything else to consider. please confirm?

 

Third and final question

at the end of the files scanning the repair reference utility reported a number of failed files i.e. they were not processed, about 50 files from 100,000. not too bad however is there anything that could be done with these except opening them in inventor and checking for unresolved references before checking them back in to vault to validate / update the reference tables. Although There is possibly no issues with references in the files what could cause these problems , what do you suggest?

 

Much appreciated Bry

 

Message 7 of 9
minkd
in reply to: B.Rawling

You can remove imported references using the Reset Repaired References command.  Removing the TRUE entry from the XML will just cause it to be ignored during the import.

 

Yes, you can test the import on a second vault server as long as it is the same release/service pack/hotfix level as the production server.  The server name in the XML is not used during the import so changing it is unnecessary. It is simply there so you know which server the utility was run against.

 

For the 50 files with errors, it probably depends on the errors. For any files that the utility had issues with, opening in Inventor (resolving any references there), and checking them in will certainly fix the latest version of those files.  However, it will not fix any previous versions of those files.  But it may not be possible to fix all previous versions because they may want to reference a version of a child file that has been purged.

 

-Dave



Dave Mink
Fusion Lifecycle
Autodesk, Inc.
Message 8 of 9
B.Rawling
in reply to: mthomas

Dave

Thanks for your prompt reply

Great info but Just for reference , its taken 3 sessions of 8 hours to do a scan of just the latest revisions approx 105 GB of filestore. Not sure how it deals with the files or work in progress over this 3 day time period. There is just no way we can afford to have the system off line for this amount of time.

Paused the scan each evening to let the vault server perform backups etc..As if I tried to run continually it crashed out prior to completing, this is my third week of trying to sort this.

I have not  include all versions 250GB filestore. With just latest versions scanned we have approx 300 rows of fixes in the excel XML data table of which only 200 were automatically set to TRUE. I would hate to think of the data problems if I included all versions.

If vault can set these 200 to TRUE ready for the import why did it not repair the References Automatically using this info during the Update 3 install & subsequent migration?

 

As we are hoping to Purge old versions soon removing 145GB of data I can not see the point of fixing old versions if they are  to be purged anyway , What do you think?

 

To Include all versions will be weeks of scanning and fixing, if it will do it at all without crashing out in the scanning!

It has taken a 2 weeks of failed attempts and a full week scanning and reviewing to get to the point where I have an Xml data file for repairing just latest versions.

This is really frustrating as to date no old versions have been purged from the vault and nothing has been deleted unconditionally except the odd DWF file . Our Users are not allowed to delete anything! Even if a file  could be deleted due to no where used instances , they just do not have the rights. Also they were never allowed to check in CAD data through the Vault Client Application , All data has been checked in through the Inventor Application or initially loaded using Autoloader.

Why the vault has lost the references between Assemblies and parts (assembly with no children and their parts showing no where used) is  just beyond me?

Vault should notify the user if it fails to build the references on all tasks and definately on checkin etc...

 

Looks like there is an need to keep running reference repair utility on sections of the vault to fix individual folder areas?

This makes me think that the reference repair utility is required from time to time as a maintenance routine however this is a massive overhead with regards to time taken to scan , review and sort.

 

Do AutodDesk expect Vault administrators to use this tool on a regular basis?

 

Vault should be able to retain or maintain the relationships between files as this is primarily its reason for being?

 

Sorry for all the further questions but this is just frustrating!

 

Regards Bry

 

 

Message 9 of 9
minkd
in reply to: B.Rawling

You shouldn't need to take the system "offline" while the scan is taking place. We understood how long it would take on large datasets, but the only way to be sure if vault had all the correct references was to crack open each assembly.

 

During migration we repaired what we could, but there were plenty of cases where we just didn't have the information. 

And to crack open each assembly during migration would mean the system would be offline for the duration, which would not be acceptable. BTW, I'm pretty sure no-one likes this thing - and we really hate the fact that it was ever necessary. But I realize that is not much of a consolation.

 

If you don't care if you have some issues resolving references when opening older versions, then there is no need to worry about anything other than the latest versions.  Before importing the XML, in a clean workspace try opening one of the parent assemblies that showed up in the output in CAD to see what I mean. IMHO, since most data modifcation workflows involve the latest versions, those are the most important to repair. But of course, if you are using revisions some of those historical versions may be pretty important, and you might not want the hassle of resolving references during the open from CAD.

 

If you've never ran a purge before, then there would be no reason to run this utility in the first place. In that case, the only thing the utility would find is broken relationships due to unconditional deletes; or missing relationships due to checking in CAD files with Vault Explorer instead of the CAD add-in.

 

The problem that started this whole mess was due to purge being too aggressive about what it could safely delete. The check-ins from the CAD add-ins were never an issue, however some workflows like property edits or renames after doing a purge would propagate the problem since those workflows copied the existing references forward; so if there were any missing, they would be missing in the version created during those workflows too.

 

Running the utility should be a one time thing. Purge no longer will delete versions that are needed to ensure relationships are correct.

 

-Dave



Dave Mink
Fusion Lifecycle
Autodesk, Inc.

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report