Starting in December, we will archive content from the community that is 10 years and older. This FAQ provides more information.
Trying to get some insight into why vaulted and released files that are opened locally in Inventor are not dirty, but when closing the file I get a prompt to save the changes? Note that I have screencast but it can't upload the recording (IT will have to look at that).
My team have suffered with this for 5+years.
Greatly appreciate all who look at the video link below and offer suggestions.
Vault and Inventor are fully patched. VAR has greatly helped over the years to fix this but cannot. Have involved ADESK support several times, even supplying Vault database, and I get "can't replicate it here" which is not a viable solution.
Note that this assy file does have some Frame Generator components which I have not had real love of over years (FG is great, it's interaction with Vault (or Vault/Inventor combination) seems flawed).
https://drive.google.com/open?id=0B2CmrzzxkVZ3T3F1RklUem9GVGs
Although the information can be non-user friendly.. If a file is being asked to be saved (and you think its not dirty).. Bring up Inventor Help/About Inventor. When the about dialog appears, perform a CTRL+D and you should see a dialog like this:
The items checked will tell you why it needs a save. But like I said the information is little unfriendly.
Sorry disregard what I just said... I watching your screencast at the same time I was writing and I noticed you did perform the CTRL+D workflow.. My bad..
Mark Lancaster
& Autodesk Services MarketPlace Provider
Autodesk Inventor Certified Professional & not an Autodesk Employee
Likes is much appreciated if the information I have shared is helpful to you and/or others
Did this resolve your issue? Please accept it "As a Solution" so others may benefit from it.
Thanks Mark.
I'm all over that like white on rice. Been using it for years, sometimes it helps (eSchemaMigrateCmd in particular).
The reason is eUnspecifiedEditCmd which makes the Database Considered Dirty flag also get ticked.
I have pleaded for more info on the meanings for the years I have know about them, but it falls on deaf ears (seems to be some super secret squirrel business).
Of note is that when I close the file and it asks to save, if 1 select No the file closes, then if I open it locally again it's not shown as dirty until closing it. I think this points to Inventor being the culprit, but why is the question.
I assume you don't have any iLogic programs running on a given trigger especially on open/save functions..
Anyhow this issue has been around for many years and people like me just accept it, save the file and move on. I know its not the right thing and we all would like a solution for it. I think @Curtis_Waguespack even has something in his signature about an Inventor idea regarding dirty files. I can't remember or not (and Curtis or @cbenner can clarify this).. But we may have brought this up at AU (this year) at the Inventor round table discussion with the Inventor development team.
Mark Lancaster
& Autodesk Services MarketPlace Provider
Autodesk Inventor Certified Professional & not an Autodesk Employee
Likes is much appreciated if the information I have shared is helpful to you and/or others
Did this resolve your issue? Please accept it "As a Solution" so others may benefit from it.
Nope, only have external rules that run when I run them.
Agree, it has been around for years. Agree that I just ignore it and move on, being aware at what state the file/s is in and if updates are actually needed.
It's just a difficult set of events to deal with when teaching a new user. They don't have the knowledge yet and tend to think the application must be right and do a save, even on released files, which I guess is not so bad considering they can't change the Vaulted version.
So, did "the knights of the round table" get anywhere with Dev Team?
@brendan.henderson wrote:
Nope, only have external rules that run when I run them.
Agree, it has been around for years. Agree that I just ignore it and move on, being aware at what state the file/s is in and if updates are actually needed.
It's just a difficult set of events to deal with when teaching a new user. They don't have the knowledge yet and tend to think the application must be right and do a save, even on released files, which I guess is not so bad considering they can't change the Vaulted version.
So, did "the knights of the round table" get anywhere with Dev Team?
Hi brendan.henderson,
I only skimmed this topic but here is the link Mark.Lancaster mentioned ( I just removed it from my signature last week, as it has reached the top of the list now).
Another related thread based on a support issue I attempted to resolve:
http://forums.autodesk.com/t5/vault-forum/vault-library-file-smudging/m-p/6438913#M63717
The "round table conversations" were under NDA and can't be discussed in specifics, but I think the Inventor team is aware of this issue. I have no direct information on it, but I suspect it's simply not an easy problem to solve.
My request for this issue, is just to be able to determine the what and why, so we can take measures to prevent/or ID the issue that creates the situation, even if a solution isn't currently available.
I'll tag @SteveMDennis to bring his attention to this thread, but I understand if he can not comment.
I hope this helps.
Best of luck to you in all of your Inventor pursuits,
Curtis
http://inventortrenches.blogspot.com
Inventor Forum links: Inventor iLogic , API and Customization Forum | Inventor Ideas Forum | General Inventor Forum
Thanks for chiming in Curtis. And thanks again to Mark for tagging you.
I'll digest the other links soon. And am hopeful the Dev team and @SteveMDennis can shed some light on this very frustrating (but not a show stopper) and continual problem.
Curtis_Waguespack wrote:My request for this issue, is just to be able to determine the what and why, so we can take measures to prevent/or ID the issue that creates the situation, even if a solution isn't currently available.
Just a quick clarification, one of the solvable issues for Autodesk here (as I see it) is that currently it is extremely difficult / if not impossible for a user to determine a migration issue (solvable by the user) vs. one of the other issues (not solvable by the user) when this message is presented....leaving the user to do not much more than throw their stapler against he wall.
The CTRL+D workflow (that I learned from Mark.Lancaster) helps a bit if you know that secret handshake, but the average user needs to have more information about the "why" when they encounter this. The CAD admin needs to be able to have some tools to figure some of this out on a larger scale as well.
Inventor Forum links: Inventor iLogic , API and Customization Forum | Inventor Ideas Forum | General Inventor Forum
The administrator having more info about the various flags in the Save Status (diagnostics) window would be a truly fantastic help. Some are self explanatory, others very cryptic (a bit like the Unknown Error in the Job Queue). Obviously there is a set of criteria that is being checked and if condition is met, flag the corresponding line/s.
For the average user this knowledge could be very discomforting. They may think they are the cause (which they could be) but in most cases I think it's Inventor arguing with Vault or the OS. I don't have proof of that or have a method of figuring it out. I seem to remember @scottmoyse detailing a method but I can't track it down.
I stopped this behavior by turning off Express Mode— App Options > Assemblies > Enable Express mode workflows (saves graphics in assemblies). I didn't find this solution myself, I'm sure it was on this forum, but I don't recall who posted it.
The reason the assembly gets dirtied (every single time, after I check it in!) is apparently that the Express graphics get written to the file right at closing, so it's seen as dirty every time it closes and needs another save. Until I turned that option off, I simply ignored that routine last save request. But it seems to me (disclaimer: not a professional coder!) that it shouldn't be a very difficult change to prevent that scenario, perhaps by writing the Express graphics at save instead of at close?
Sam B
Inventor Professional 2017.3
Vault Basic 2017.0.1
Windows 7 Enterprise 64-bit, SP1
Inventor Certified Professional
@brendan.henderson @Curtis_Waguespack @Mark.Lancaster @SteveMDennis
I've seen this for years also. One of the things I have noted in recent years (that may or may not have anything to do with this). Is the behavior of migrated files. Let me clarify:
I have an assembly that contains "x" number of library files, content center mainly. I work on it, and I check it in to the Vault. I am prompted for the migration of a certain number of these library components, as they may have not been used in a while. So, I save: Yes to All in order to get the migration, and finish checking the assembly in (delete working copies). The very next day, I check the assembly back out (get revision - check all). Work on it some more, and go to check it in again. I am prompted to migrate the very same library files that needed migrating the day before. So, I can't help but wonder: If I have checked out these library files, saved the and migrated, deleted working copies and tucked them away nice and neat where they belong.... how can they possibly need to be migrated again the next time they are checked out? I have no answers, but it does raise the eyebrows.
Like I said, this may be a totally different issue. But it seems to me that the files I find dirtied the most are the ones asking to be migrated.
Chris Benner
Inventor Tube & Pipe, Vault Professional
Cad Tips Tricks & Workarounds | Twitter | LinkedIn
Autodesk University Classes:
Going With The Flow with Inventor Tube and Pipe | Increasing The Volume with Inventor Tube and Pipe | Power of the Autodesk Community | Getting to Know You | Inventor Styles & Standards |Managing Properties with Vault Professional | Vault Configuration | Vault - What is it & Why Do I Need It? | A Little Less Talk - Tube & Pipe Demo | Change Orders & Revisions - Vault, Inventor & AutoCAD | Authoring & Publishing Custom Content
The video is not very helpful in diagnosing your problem. Can you do the following? Save a copy of the original file as downloaded from Vault under different name, then perform the prompted save of "39335-00000.iam", and then post both versions here (i.e. before and after - don't need the referenced files)?. Comparing these two file versions will probably lead to some more insight of what kind of changes Inventor has actually performed to that file.
Aye is it safe to pack & go that entire assembly into a zip and attach to the thread? Opening that outside of your environment might help at least narrow it down to being an issue with the file or something you've maybe got running in session. Given the VAR can't reproduce, I would imagine you guys have already established its a session thing though.
Apologies if you've done this already, or if someone else mentioned this, but first thing I would try is open Inventor, disable every single addon even the standard ones, switch to the Default project, reset the application options if you've changed anything like the default IVB, then open the files and see what happens. Then if you get normal behavior, start reversing everything one thing at a time until you hit what causes it.
Soz if I'm stating the obvious, that's the way I would go with that.
Hi Sam.
Seems a fix to the problem. Initial tests show that it works on the assy file I took the video of and other assy files. I'll continue to monitor it and report further outcomes.
Thanks Sam.
Hi Chris.
I'm all over the migration aspect. The assy and children are all new so migration isn't the issue here. But it has been on other files and is a very valid cause of the dirty file, resulting in the dreaded eSchemaMigrationCmd being flagged.
Thanks Chris.
Hi Bert.
Attached are 2 simpler assy files that exhibit the same Save prompt. And there are no FG members here to muddy the waters.
39313-00000 is the original file that asks to be saved every time but NO has been selected. 39313-00000-A is the same assy file where YES was selected.
Appreciate you looking at these and adding your thoughts.
Hi Neil.
Attached is a smaller dataset that exhibits the same problem.
I have completed the task of disabling add-ons and custom code and such before with no change. I have not resorted back the default project and such. If all else fails I will go down that long path.
Thanks Neil.
So I have gathered together a couple of the suggestions you fine folk have offered up, namely the turning off of nearly all of the add-ins (only left the 3D mouse on) and tried with and without the Express Mode setting and with the Default project.
Below is a link to video I took of the simple assembly file I posted previously, no Frame Generator of Design Accelerator bits, just Content Centre parts. Note that I have disabled ALL add-ons except the 3Dconnexion (3D mouse) so I can manipulate the view if needed. The first part of the video shows that I have Express mode turned on and that when closing the file it prompts for Save. The next section of the video shows that I have Express Mode turned off and open and close the same file without a Save prompt. I then turn Express Mode on again and open and close the same file and get prompted for Save. The last section shows that I have changed to the Default Project and am opening the same file with Express Mode on and that closing the file does not prompt for a save.
Thoughts?
Hi Brendan,
If you check Tools, App Options, Save tab are you using "Prompt for Recomputable Updates"? If so then that likely explains this issue. That may be forcing an update & consequentially flagging the cached Express data to be updated too.
The need for a "Why something has changed" as opposed to the ambiguous CTRL-D is something often discussed (argued about???) here, but we unfortunately haven't delivered it yet.
Thanks
Chris
Hi Chris.
I have that setting turned off. This is also the case in the videos I have supplied.
Can't find what you're looking for? Ask the community or share your knowledge.