Autodesk Vault

[#1]

When I go to save my parent document (assembly or drawing), sometime Inventor prompts you to save a reference file (model) you never edited.  Sometimes you can simply open an assembly and some of the reference say they need saving (how is that even possible, I didn't modify a thing)!  Based on the message (Yes, Write Enabled not checked out from Vault) it made me think somehow the file's read-only attribute somehow got turn off but alas read-only is on as it should be.  What does this message even mean?

I know I can do a checkout then check it back in to resolve the situation but it's undesirable to populate the Vault with unwanted extra versions just to resoves some qerks.  What causes this and is there a better workararond?

[#2]

We jumped from 2010 to 2012 and have been seeing this with legacy data.  We migrated libraries and then walked through projects folder by folder to attempt to eliminate this, but it remains.

We have been working on this with our reseller, but it continues to plage us.  The thing that puzzles us the most is why the option to write enable a part without checkout is provided...this seems to contradict what the vault is supposted to help do, and that is prevent users from overwriting each other's work, etc.

One thing I'm wondering...I know we have multiple parts that were checked into the vault as "part 1", and then renamed later.  With the vault maintaining history as it does, could this be a root cause of the problem?  I am sure parts have been brought together in an assembly that at one time had the same name, but are now unique.  My though is on iproperties, and if something resides there that was not updated.  Also, at this time, we do not purge versions after a certain number.

[#3]

Yes!! We are not alone and neither are you!!

We primarily see this happen with our models that use a bitmap (labels, nameplates, decals, etc that are 3D modeled). I've also seen it happen on files that INV seems to think need to be migrated but they are of the current version of INV so...

You are not alone and I agree it seems silly to allow a read/write modification (on their local machine) to a file that is obviously locked in Release State in Vault. What is the ideology behind this? It would seem to me that if you want your users to only be able to modify a file they would have to go thru the proper method of check-in/out policies and procedures, otherwise what's the point right?

[#4]

Thanks for chiming in Kenny.

I'd really like Autodesk to reply to this one.  There's no good reason in my mind that a file that I have NOT modified, shows up as modified and on top of that, it can't be saved!  Thank god there's a workaround (checkout then checkin) but this should be fixed. 

My opinion is Autodesk is way too marketing driven, meaning they'd rather add new functionality rather then fixing the sins of the past.  I know Autodesk can't sell bug fixes as a major release (although I wish they would) but we've been living with some of these bugs for many years.  Also, now that Inventor has matured to an extent, there's not that much new functionailty that we'll tend to utilize in each new release (we use the basic command set, no molds, no sheet metal, no multiple bodies, etc), the point being, bug fixes/performance improvements hold more weight with our group than does new functionality.

[#5]

I very much agree with the setiments here...I really like Inventor, and the bundled software provided in the suites.  I have taken advatage of features in programs like Showcase and Sketchbook that I otherwise would never have done if these programs didn't "come along for the ride".

However, the core of what so many of us do is dependent upon Inventor and Vault.  This is the "heart" of the software and should be a primary focus.  What concerns me most is that we have users grumbling and talk has started of "I never had these issues with (insert another software package name here...solidworks, solid edge, etc.).  I'm not foolish enough to think that any one single software is flawless, or we would all be using it.

If I may be so bold to offer the suggestion to Buzz and the guys at Autodesk...in this economic climate, companies are looking to maximize the output of their current staffing.  Hiring more bodies to fill seats is not happening fast, but looking at what will improve output is.  If that means evaluating competitive sofware because the curent software is limiting productivity, it will, and is happening (read between the lines here!).

I urge you to focus on known issues and work on resloving them.  I can tell you this much...my company is on subscription, but we will be holding on 2012 for the next 2 or 3 releases at this point.  We will monitor the trend of how issues are being addressed, and assess what our move forward will be, upgrade, or move on...

[#6]

I would like to thank you all for the valuable feedback. Letting us know when you have issues like this helps us to know when issues exist.

While I can not make promises as to when this workflow can be changed.

I can say that this particular issue is something that we are currently taking a hard look at.

[#7]

---

cadfish1 wrote:

....I know I can do a checkout then check it back in to resolve the situation but it's undesirable to populate the Vault with unwanted extra versions ....

I feel your pain.  You have to stay on your toes when saving your work.  They have it in there so "IF" you are ever doing a "What-if" scenerio, you will not lose your work.  I think they have this backwards.  It shouldnt default to save the local file, rather, it should NOT save it by default.  Then, IF, you do want it saved, you can change it to yes.

Hopefully they will get it straightend out in a year or three.

No problems with the extra unwanted versions.... just use the "Purge" command.....  OH!, I forgot, it doesnt work either now.

[#8]

"No problems with the extra unwanted versions.... just use the "Purge" command.....  OH!, I forgot, it doesnt work either now."

When is this going to be fixed? or does all support for Vault 2012 and earlier editions get shelved since 2013 is out now? 

[#9]

karthur1,

That is the same way I've always felt in that they have it backwards. I understand building in the "what if" scenarios (otherwise we'd be complaining why they didn't include what if scenarios heh) but they should make it so that its not the default methodology. Besides for those what if's I typically would save copy as and apply my design (or re-design) to the legacy file once I'm happy with it, should it need it. Is this the most efficient means? Certainly not. But it's better than the current alternative where I feel I can't even trust to use the Workspace Sync feature in fear of losing some data inadvertanly or having to deal with the whole read/write on Released state file issue entirely.

It still doesn't explain WHY it's trying to update or it feels the need to modify a file without you deliberately wanting to. Nothing gets in my way more when all I want to do is edit a top-level assembly but INV and Vault see some file buried deep in one of the many sub-assemblies that the software feels some need to modify for one reason or another. Glad to see they plan to work on this matter as it seems to get a little worse each new release of software. We've been on Vault Professional since 2010.

And yes, the Purge command for file versions has been broke or doesn't work since at least 2010 or so that's been our experience. Thankfully the little button is there to hide all the minor revisions (versions) but still it would be nice for it to Purge any and all minor version history should the admin choose to. Nothing more frustrating than any software no matter the make tells the admin they don't have "adequate permission" to do something lol. That is a Windows mentality and no I'm not a MAC guy I'm just saying that's how it is or where it seemed to originate from heh. Sorry this should be in a seperate topic but I had to add on that rant. I apologize to the OP.

Best regards,

[#10]

Question for those out there dealing with this.  We have several companies under one umbrella, and each company has it's own dedicated server and vautlt databse.  We all stay on the same release, but each manages their data independently. I get the pleasure of being the main Admin for all...no, it's not all it's cracked up to be...don't even talk to me about enforcing standards...

Anyway, the database we have the most trouble with is for a division that does large machine assemblies and uses a lot of legacy data.  I've seen assemblies with 40,000+ parts.  The main designer tends to do his design work inside asemblies by creating parts and just naming them as "part 1", "part 2", etc.  These get checked into the vault in this manner, and then changed to a unique part name later.

I know for a fact that there are some parts that were originally named "part 1" that have come together in assemblies, and now reside in a common folder path.  With all verisons still in the vault, I'm wondering if the vault still "sees" these names, and it's causing some of the issues we are seeing. 

The thought process behind this is that the group working out of the vault I use always give parts unique names at the time of creation, and I have never seen these errors in this vault.  I have even pulled up designs I know were never migrated going back to relase 2008, and they open/convert to 12 just fine. 

I'm not making excuses for things that don't work as they should, just trying to find some kind of resolution.