I recently checked a couple small assemblies into Vault from Inventor 2013 from one computer then came to mine and checked it out to do my thing. I then created a drawing and checked both back into Vault. Everything seemed to be working fine until I tried to Assign Item to the assembly in Vault. I get Error 1455 which reads: The file was added in a way that did not include the correct item data.
What did I do wrong?
What can I do to fix this issue?
Thanks
Scott,
Was the CER send out when Inventor crashes?
Historically yes lots of them have been sent out. Dozens and dozens, since we have had inventor crash with idw check in lots of times this year.
We think the one today was sent out, if not they have been on previous days. The computer name is Design_31
Scott Moyse
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
Design & Manufacturing Technical Services Manager at Cadpro New Zealand
Co-founder of the Grumpy Sloth full aluminium billet mechanical keyboard project
I wonder .. does anyone of users that suffer the 1455 issue is working in replicated environment?
Getting this error here as well, so this thread has been some great reading material for the past 20 minutes... Haha!
We, too, have been getting a lot of Inventor crashes when checking in files. On that note, I did notice in the Vault update 1 Readme that many crashing Inventor issues have been fixed. We will try and get the update on as soon as possible and see if that maybe relieves the issue, but I was wondering if someone here can comment who has tried the update already?
We put the Vault SP in last week Thursday and the Inventor update on Friday, so far no new error 1455's but we've really only been at it for a day
Its baaaccckkkk and with a vengence, we are seeing a lot of files / items the past 48-hours displaying this same issue.
It seems to have started again since applying Update 2 for Inventor 2013. I'm going to try removing the update from my system and hopefully it makes the difference
Mike
keep us posted I was just about to install this
Scott Moyse
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
Design & Manufacturing Technical Services Manager at Cadpro New Zealand
Co-founder of the Grumpy Sloth full aluminium billet mechanical keyboard project
Are all associated files with any of the items your working with checked out?
If yes, try checking in all files and see if this fixes the error 1455.
If not, are any of the items in work in progress that have been previously released by a controlled change oder?
If yes and you are recieving the error, this seems to be an issue for Autodesk to inspect.
It is looking like it is not related to Update 2 for Inventor, just a really big coincidence that the issue has reappeared
I took 3-assemblies yesterday, 2 that I was trying to assign items for the first time and one that is already assigned to an item but is in WIP and part of an open change order
For the first two I checked out all, rebuilt within Inventor and checked-in deleting the local copies and was able to assign items. I did check prior and nothing was checked out.
The 3rd assembly in question is attached to a change order, but this is the first change order that it is involved in and the change order has been created to release the item for the first time. We're stuck in the work phase as we can't update the item to change it to In Review. I tried the trick of check-out all, rebuilt, check-in deleting local copies with no luck. I also checked and none of the files were checked out prior to me working with it.
I did have a conversation with Autodesk Tech Support yesterday but there was no resolution
I also had this error recently. More than one assembly and draughtsman experienced this issue on the same day. After some investigation I found that it came down to one part that had an issue. This part was used in most of the assemblies giving this issue.
I also found that the file's part file (ipt) was checked out by one person and the drawing file (idw) was checked out to a different person in the same timeframe. I think this might have caused some confusion or corruption in vault which caused this error.
Never the less checked out the current version of the corrupted file, then performed a get previous revision to replace the latest version with a previous version that did not have issues. I then made that version my latest version did a vault update, rebuild saved and checked it in using the "delete working copies" option. The part updated correctly and after this all the other assemblies that gave the error 1455 updated and assigned without issue.
Hope this helps.
Regards
Kevin
Today I have got the same error.
I made a revision to a part and drawing and checked them in. When I updated the item, it resulted in an error.
Is there already a real solution to this problem?
I'm using IV2013 and Vault Pro 2013.
I already found a simular work-around for solving this problem, but thanks.
I mainly posted it to trigger the developers of Autodesk to look deeper in this problem.
Somehow a file gets corrupted.
Solving the consequences for an enduser is easy, but that isn't solving the problem.
Next time try removing all file links from Item and then set them again one-by-one trying to update Item after adding each new link…
We've started running into this in one of our instances.
Here are the error log details
9/23/2013 1:59:25 PM *******************************************************************
Error: Soap Exception ( mesg-id = 635155415655533379 )
Exception: ItemProvisionalComponentDataInvalid [1455]
Stacktrace:
Server stack trace:
at Connectivity.Product.Services.ItemService.ProcessBOMBlobs(Hashtable allboms, ArrayList newBoms)
at System.Runtime.Remoting.Messaging.Message.Dispatch(Object target, Boolean fExecuteInContext)
at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Connectivity.Product.Services.ItemService.ProcessBOMBlobs(Hashtable allboms, ArrayList newBoms)
at Connectivity.Web.Services.v17.ItemService.AddPromoteComponents(Int64[] fileIds)
Exception(Inner): ITEM_INVALID_PROVISIONAL_DATA: current link is not provisional
Stacktrace(Inner): at Connectivity.Product.Services.ItemService.ProcessBOMBlobs(Hashtable allboms, ArrayList newBoms)
It looks like it was related to the "Associate File Link Type". In an AutoCAD mechanical drawing, there was a subcomponent. Assigning an item to the drawing created an item for this subcomponent (which did not previously exist). This created a "Primary Subcomponent" type link type for this part.
When we tried to use that part (the subcomponent) in another drawing, we would get error 1455 when we attempted to assign an item.
We changed the Associate File Link Type to a "Standard Component" and the error went away.
I fixed mine by changing to Quick Change, checked out the entire dataset relating to the assembly BOM itself, pushed a property change into every component, Rebuilt All, Updated Mass calculations, checked it back in & assigned items. Phew. but Ridiculous all the same.
Scott Moyse
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
Design & Manufacturing Technical Services Manager at Cadpro New Zealand
Co-founder of the Grumpy Sloth full aluminium billet mechanical keyboard project
In just about all cases for us its because one file is checked out, once we locate that one file and check it in the error 1455 goes away
In some odd cases we need to checkout everything, update, and during checkin delete the local copies and then the 1455 goes away
Mike
I've found this to be the cause of the issue for us as well in AutoCAD.
If you try to assign an item to a file that has 2410C in its BOM, and one of the other associated files has a later version number than the one shown on the item, the Assign Item wizard will attempt to update the item for that file as well. If 2008070200GD01 has a latest version number greater than 20 and that file is checked out, you get an Error 1455.
This doesn't seem like intended behavior, more like a hole in the logic used for updating items. If a file other than the one that the user selects is checked out (i.e. one that the Assign Item wizard decides needs to be updated), the process should be allowed to continue and it should be assumed that the item associated with the checked out file will be updated when it is checked in.
I personally think that once an item is assigned to a file, the item and its BOM (only one level down) should be updated based on a lifecycle transition or every time the file is checked in. This would avoid the need to chase through all levels of an item's associations any time it is updated.