Major Issues with Vault Pro 2015 Items

[cbenner]

We just upgraded from Vault Pro 2013 to Vault Pro 2015.  We use both Items and Change Orders.

We have been having issues since we switched, with properties on Items that are attached to ECO's not updating to the file.  We use Item Properties to update our Revision blocks.  Long story,.. it's worked great for 2 years.  Investigation revealed that when we use the Update All tool from the Change Order, to update the Items, a duplicate Item is created.  This new Item has a different item Number using a different numbering scheme.  I has none of the Item properties that we normally use filled in... and it "steals" the file attachment from the original Item created under 2013.  All attempts to delete this Item and reattach the file to the original Item have failed.  So, at this moment, I am faced with re-creating these Items from the original file, and manually re-entering all of this property information.

A test ECO I just created, exhibited this behavior so I was able to confirm that the duplicate Item was being created on Updating from the ECO.

I'm hoping that someone can re-create this behavior and tell me I'm not nuts... and hopefully come up with a fix.  For a work around I am going to try updating Items from the Item Master instead of the ECO... adding unnecessary steps to an already convoluted workflow.

[achintam]

Hello Chris,

Thanks for the post. We are unable to reproduce this issue that is described in your post. Can you reproduce this everyone on any item that is on a change order? You said the new items are created using a different numbering scheme. Can you please tell us which numbering is being used to generate these new items?

Also, have you tried the workaround (updating the item from Item Master) that you suggested in your post? Does Update on an item work fine when it's run from Item Master?

Thanks

Anil Chintamaneni (Autodesk)

[cbenner]

Hi.

So far any Item that is updated in a Change Order is duplicated.  I just did an Update directly form the Item master, and it also Duplicated the Item.  The numbering scheme that was being used for these duplicates was "Mapped", which is currently turned off, and was NOT the default in any case.  Now in this latest test, the new Item was created using Sequential which is the default and the only scheme turned on at the moment.

[cbenner]

I now have three Items form this test.  Each new Item created, when Updated, creates another new Item. Note the Date Modified.

[achintam]

Based on your description so far, here's what I am interpreting...

100204 was the original item that had the file association.

When you updated 100204, the file association got removed from it and linked to the new item, 100205.

And when you updated 100205, the file association got removed from it and linked to the new item, 100206.

Is that true?

Thanks

[cbenner]

That seems to be the case. And any properties we have set, along with all Item history is lost on the new Item. Also should mention this is happening on both client machines.

[KooCheeKit]

Hi Chris,

What are the value of the "Equivalence Value" for the 3 items? This may give us some clues where when wrong.

[cbenner]

Equivalence for all of these Items, including the original, is False.  Does that say anything?  I'm hoping this is somehting I have set wrong... because that means it's somehting we can fix.

[cbenner · Accepted solution]

I think I may have found it.  Auto Select first Duplicate was UNCHECKED, this was not how I had it set up before.  Early results appear to be good.  So far no duplicates.