"Yes, Write Enabled not checked out from Vault" but I didn't modify the file

[cadfish1]

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?

[WJH1970]

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.

[kwilson_design]

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?

[cadfish1]

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.

[WJH1970]

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...

[mikel_martin]

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.

[karthur1]

---

@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.

[BL4849]

"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? 

[kwilson_design]

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,

[WJH1970]

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.

[cadfish1]

I know this thread is vault related but I think this should be it's own thread in the Vault decussion group.

What problems are you seeing related to default file naming (Part1, Assembly1, etc)? 

[kwilson_design]

whenry,

As mentioned this should be in a seperate thread as it doesn't necessarily pertain to what we are discussing. Perhaps a mod or admin can merge these posts with the appropriate thread?

For starters its never a good idea to use generic names in a database (save for maybe custom CC libraries iparts etc in some situations). Renaming the files after the fact in Vault is OK.... but..... there's always the "I'll get around to renaming it or 'fixing' it but either forgot or doesn't have time" thing, which is setting themselves up for disaster in the making. And we all know people tend to forget or 'not have time' to go back and right the ship so to speak meaning renaming the fileBeen there done that. It takes a few seconds in our company to assign a new part number and description and then apply that to the model. I understand working within an assembly to create parts 'on-the-fly" as its been my experience that many machine designers work in that workflow. But...it's better to take the time to assign the models created on-the-fly with their unique file name upfront as it saves time and work for the poor soul who has to maintain the database. Team effort!

[WJH1970]

To all...my apologies for going off topic here, that was not my intent...just kind of got carried away.

In the "for what it is worth" category, my local resller has been trying to help on this as well, but the best they can really do is push Autodesk to help.  I actually feel bad for them, as it makes it look like they don't suppor the software well, and there is really little they can do.

[mikel_martin]

This issue is not caused from renaming files in Vault.

The biggest problem is that with any parametric modeling system, when something changes those changes can have unforeseen effects on data that doesn't appear to humans to be related at all.

The main problem is that CADs systems are trying to update the files and Vault is trying to control them.

We are working to find a better way to handle the conflicting needs of the two systems.

[CelticDesignServices]

I typically see this issue come up when users have activated a local, non-checked-out file, for whatever reason. MOst likely thinking they are opening the Vaulted version (the most common statement I hear is "I opened it from my local Vault").

When they attempt to check the assembly back in, they get the "Write Enabled" list and they will most likely select the "Yes to All" button and that in turn creates more issues, especially on files they don't have checked out. As you all know, you can't "write" a file that is set to "read only".

As I mentioned in another post along these lines, I recall a few releases ago where simply opening a file and using the zoom command or the like, causes Vault to see a "change" in the file took place. Could that be the same deal here? It sure sounds like it. But mianly, as Mikel states, there are a ton of things happening to these files that we just never see in the foreground. Vault, like any other PDM is always attempting to synchronize the file from your local drive to the last version that was stored into Vault and these are items that are more than just visible properties we see in the model/drawing graphics.

My typical process is if I see a file on the list of "Write Enabled" that I know I didn't modify yet it's set to "yes", I simply select the 'yes" and toggle it to "no"....or I'll stop the process and check that file out so it updates accordingly, then check everything back in. It seems to work fine after that.

Just my 2 cents

[kwilson_design]

In my experience it's happening when the assembly IS checked out from Vault and is local. It's some component (part file) within that assembly that is the offending file in question. I'm also still trying to wrap my head around why Inventor part files that use a bitmap constantly will throw the "write enable save" prompt if you are working on an assembly that uses that  bitmapped part file. Every single time I work on any assembly that uses some part file that has a bitmap I will see it wants to force me to do a write-enable save on it even though nothing has changed! Makes zero sense and yes there are a ton of things going on in the background.

As far as checking the "offending file" out that is wanting to update from your assembly data set, well to me that is not an option in our case. To me that would seem like a horrible and "long way work around" bandaid to a glaring issue within the software(s). It does not necessarily solve the issue at hand. We have a specific group of users who roles are the "ECN Checkout Group" meaning they handle the task of lifecycle state change upon emial request from the 'regular' users. The Checkout Group has Document Lvl 2 Editor and Manager roles.  The 'regular' users only have Document Lvl 2 Editor role, so they do not have the ability to change lifecycle states. Doing what you mentioned isn't a viable option as it would cause our ECN Checkout Group to change lifecycles state from Released to Quick Change state (so that you don't bump the revision in Vault) only so that 'regular' user within the company can make his assembly happy because it saw some rogue file it felt the need to update. It should not have to make more work for anyone. If I allowed all the users in our company to have the ability to change state whenever they want It would be massive chaos to the ninth degree hah! Might not be that way in every company out there but here we have lots of users and like everywhere else, some good and some bad. I just can't stomach the idea of potentially allowing my database to go south if I 'opened the flood gates' so to speak.

How are you selecting "No" and still checking in the assembly in Vault??? If I tried that Inventor would not allow me to check in the assembly or drawing until I/we eventually cave in. It FORCES us to select "Yes" on any write-enabled files otherwise it will not allow check-in as it will throw the (paraphrasing here) "this file has dependants that need to be saved before check-in..." dialog with the big red X. It would be one thing if Inventor (or Vault) would allow you to save the assembly and NOT have to click the "yes" on any file that shows it is write-enabled. The problem is a) it's doing this on its own without user input b) forcing you to have to save these files (otherwise you will not be able to check in everything from the drawing (IDW) level. It is a huge pain to deal with this and I hear the grumblings from our users constantly. I have run out of 'excuses' to tell them to try and defend the software. But in this case I have nothing to tell them of why but only to tell them the 'work around' for getting past all these save prompts.

[jpealo]

I have thousands of files with this issue....I've held my breath on a fix as I loved this software...no longer!

We've looked at every major alternative CAD systems and for us NX looks to be the best choice. We've ended our subscription with our reseller and we're saving those dues to buy NX.

Good luck to you guys looking for hope and change!

[warrentdo]

I know that this is an old post but has it moved on from here.

Do we have a solution?

We are currently seeing vaulted files assemblies change to red when nothing has been modified thus causing checkout check in.

Regards

Warren.

2011 AIP

[drguitarum2005]

x2 on an update on this. This is the root of most of our problems and is the reason so many of my coworkers keep losing work and having issues. I find myself spending more time fixing their vault issues than actually working on my own stuff. We are seriously toying with removing Vault altogether...

[mikel_martin]

If you are on the latest version of Vault Workgroup or Pro (2014) there is a subscription update available that should help releive this issue.

It wont stop CAD systems from modifying the local file. However, we have changed the way that Vault reacts to those changes in order to help the user have a better experience.

Here is a link to a great write up from Michael Thomas at Design & Motion, which includes a video of the change.

http://designandmotion.net/new-post/autodesk-vault-2014-subscription-release-1/

As he says in the post: "If you are using Revit or Inventor this is a must-get, must-apply, update… stop everything you are doing and get it now"

Hope this helps.