Multiple Items assigned to single files

[ebuckner]

We were forced up to 2015 from '14 by the item locking issue and we now have a critical issue in 2015. Upon assigning or updating assemblies we are seeing a lot of our library files being assigned to new items when they were already assigned. This results in multiple items being attached to single files and BOM's that look like hell, full of duplicates. Our clean items are used to directly link to MS Axapta and these effected assemblies are now rendered useless.

Way back when, 2010?, we had the same issue and the culprit was a "BOM bit" issue in the file or item. This happened very infrequently and was managable. This version is an absolute horror, 62 instances of multiple items in the last few hours.

ADESK, what's going on here? Is there a data issue I should be aware of?

Inventor 2014 Pro 64bit Build 246 SP2
Vault 2014/15 Pro Admin Update 1
Windows 7 Ultimate 64bit
Intel Xeon E5-2643 @ 3.30GHz
32GB RAM
Nvidia Quadro K5000

[ebuckner]

Here is a screen shot of the issue. The file was assigned to # 32551, way back in 2010 I guess since the history has been wiped out as well, but upon use in a new assembly a new item has been assigned under the X000 designation.

[tmoney2007]

I'm not sure how different it is in 2015, but in 2013, there is a property on the items called "equivalence value" which should be equal to the item number.

In 2013 at least, this is what is used to match the part numbers of files to the item number of existing items. I.E. If the Part Number of the file matches the equivalence value of the item, it uses the existing item, otherwise it creates a new one. 

Were there any changes to the item property mapping settings?

[ebuckner]

There was no change in the mapping from 2012 to 2014, then to 2015. It appears that the item or file no longer recognizes the fact that they're linked and as such generates a new item. We have our item numbers mapped to the stock number field with a fall back to the X000 format should the stock number already be consumed, hence the new item number begins with X000.

Interestingly, when I right click and select Go To Item on files that have dual items assigned to them I get an Error reading Sequence contains no elements. If I delete the old item (the one with the correct number) I can right click, Go To Item and it works fine. Something is corrupt and it's not consistent, even among iPart children.

[ebuckner]

Going to run an Update File References Action on the library tonight, see if old links are the issue.

[ebuckner]

Update file references did not help.

Logged with Ketiv and ADesk who have already made exceptional efforts in finding the cause/cure.

[ebuckner · Accepted solution]

Autodesk and Ketiv worked with us late Tuesday and Wednesday to track the issue down and provided a hotfix last evening.

It appears that the problem was related to the Equivelant Value field in the items. We've been using vault since it was productstream 4 and way back then this field wasn't used or at least it wasn't important to populate it with anything. In either case the items (+/-15,000 items) from this period had blank Equivelant Value fields and in 2015 when this field is blank the update process generates a new item.

I will monitor the system for a couple of days before I assecpt as solution but testing last night seems to indicate success.

[ebuckner]

After some watching and waiting the solution above appears to be 100% sucessful.

[tmoney2007]

Yeah, I don't know why they use that value to match items,... it seems like Number would be the correct thing. Unfortunate that they didn't fix that in 2015.

We found the same problem when someone (...ok, it was me...) deleted that mapping because it seemed extraneous and the same thing started happening.

[ebuckner]

If it's so important I don't really understand why it isn't internal, non editable. Oh well, ADesk got right after it in any case.