Stop telling me I need to save something I haven't changed

[andrewiv]

Inventor shouldn't be prompting for a save on a file that hasen't changed.  I'll give an example.  I insert assembly1 into assembly2 and set it to positional rep1.  I save assembly2 and close it.  Now I re-open assembly2 and it asks me if I want to update.  I say yes and now it asks if I want to check out assembly1.  I say no since I haven't done anything to it.  Now Inventor tells me that I need to save assembly1 and assembly2 even though I just saved them and the only thing I have done is open them.  I think this is wrong and it can create a ton of unneeded versions of the assembly when using vault.

[Gabriel_Watson]

@bradeneuropeArthur 

Just brace for impact, and use your workarounds.

It takes about a month for designers to be fully aware and capable of fighting this back, if we inform them well as soon as they start with Inventor using Vault. We teach them to just update the assembly and save/edit all changes locally, but check in only the top assembly/drawing and children we have modified. That can be done either by checking in a child file and including parents (cheat 1), closing the file and save+checkIn at close (cheat 2), or, the rather convoluted "shoehorn" (cheat 3) I invented of checking in a blank drawing in if your drawing is being checked in for the first time, with the same name as the original, then deleting that blank drawing in local drive, renaming the original drawing back to its proper name, and then close+save+checking as in cheat 2 above.

TL;DR: update, edit, and save local files, but manage to only check in those where changes are needed.

[e.preston]

I still feel the same pain in 2021. Not sure if anyone at Autodesk uses Inventor. 

[n.schotten]

The 2022 edition isn't much better, if not actually worse.

There is a checkbox to ignore library files.

However i've noticed that when updating the assembly it updates several files and on a save command saves these. Howver it doesn't automatically, nor asks to, check out these files it's saving. So you end up with a bunch of green dots without checkmarks is the vault browser tab. So you need to do a manual chechout of these files.

And what erks me even more. Eventhough you just did a save when checking in, it still pops up a comment that there are unsaved files needing saving befor it can be checked in. WTF? What use is a save command if it doesn't save files that need saving? And often it doesn't manage to save the files, forcing you to put on your detective hat and investigate and hunt down the offending file(s).

tl;dr Saving files and checking them in is still a **** show.

[dg2405]

@n.schotten 

i fully agree with your comment about IV2022. I have a test environment and i have to say it's worse than IV2020. There are a few weird things, i think due to the new model states. They make the biggest IV-Problem even bigger!

[dg2405]

@Anonymous 

ther is nothing implemented to solve this huge problem! Please you Inventor and Vault-guys, get together and make this thing better! Don't know if you ever check-in a 70000 part assembly or drawing in a real environment into Vault, i don't think so...

[n.schotten]

BTW, @Anonymous

It would be nice if the Invetor team (together with the Vault team) would write up a proper tutorial/white paper on how to properly use the task scheduler to migrate (library) files to a new version of Inventor. To the level that Inventor doesn't have the urge to change the file at a later stage. Especialy on Iparts and iAssemblies.

Same as for a method of setting parents to link to the most recent part version as that, to me, seems to be a thing that triggers this 'file changed' status. Same ofcourse with (lower level) assemblies in other assemblies and drawings. Should this be done via the ADMS rather than the task scheduler? But how would that work with files that are checked out.

I would like a cleaner, more clear, explenation of how the migrate funtion in the task scheduler functions. Does it start with parts, then lowest level assemblies and slowly up to the drawings? Or does it just sort on part-assembly-drawing and take them as they come? Does the migration still need a run of updating (and purging) afterwards? should it be run on a non vaulted project? Having used the TS to get and check out all files first.

And what application settings to make sure that files get properly saved as not to trigger this 'file has changed' status even just moments after you saved a part and then open a parent assembly. We get informed at autodesk/retailer new release events etc about setting to help speed up opening and saving, but do these changes (defer update for example) cause the files to trigger the 'file changed'? Should we do a rebuild before we save?

Niels

[Bert_Bimmel]

Seems like unless a majority of users refuse to continue paying their annual Autodesk-Tax, they don't feel the urge to deal on problems that have been existing for ages, and noone feels responsible for, but will continue implementing fancy new features, noone needs.

Unfortunately, someone will have to implement a reverse-migration tool before, so everybody has the chance to return to the latest* version he purchased a permanent license for, and escape from the Autodeskian Blackmail.

*or maybe his favorite one, when Inventor has passed its usability peak - in my opinion around 14 / 2010

[n.schotten]

OK. So the reason i had to fight with IV/Vault to check files in is partly due to the option to not include library files (Application options-Save).

This does not (force) save library files.

However what it does is that it still marks library files as 'changed-needs saving' and they don't get saved. Nor does the save popup list these files as needing a save. So you just end up with the vaulting procces erroring out with a message that an X amout of files need saving. And no matte rhow often you hit the save icon, save in the menu or the CTRL-S combo they don't get saved.

And they are just about impossible to track down in the vault browser tap in IV. Causing even more frustrations.

And instead of library files being ignored they still get saves, Causing out of date issues with other systems that have the library in a local copy. And getting a new 'get' when they are needed by an open from vault. But when they get used as an insert you are getting the old version...

I especially notice these library save issues with iparts/iassemblies made with iparts (table replace).

Having tried to get the tasksceduler to migrate these files, including updating (and what ever else seemed possible) aperently doesn't guarantee that in the end IV thinks they are fully up to date!

Niels

[Martin.calmar]

Complety back this idea, it's driving you nuts. 

I work with the Vault and have a state workflow (Work in progress/Review/Released) and sometimes when for example deleting lets say part A which has constrains to Part B and C, it would ask me if I want to make changes to Part K? What, Part A had nothing to do with Part K, and since Part K is released I don't want to make any changes. If I say no to changing Part K, Part A isn't going to be deleted.. This is just one example of a million - Seriously fix these problems..

[Bert_Bimmel]

@Martin.calmar 

Was your "Part" K actually a Sub-Assembly? The most common explanation for what you described is a pending BOM-update of that Sub-Assembly:

When applying a new constraint, Inventor actually performs a "rebuild all" and thus, every component with pending Geometric or BOM update is recalculated.

BOM-updates are due (but not triggered automagically), when the PartNumber or BOMStructure of any of its children has changed (or a child assembly has received a BOM-update itself).

Inventor will not tell you about pending BOM-updates, but come up with them upon a rebuid-all command as already stated above (still without explanation, what it's actually willing to do).

To avoid such unpleasant interrupts, you need to make sure, there are no updates pending before you release anything (and not mess it up afterwards by quickchanging any of its components). As for that BOM update you can trigger it manually by clicking the BOM-Editor within that assembly. Again: There's no hint to the user if there actually is an update pending. So it would be good advice to just click on the BOM-editor on spec before releasing anything.

There are plenty of other updates which Inventor tends to postpone and come up with in the most unpleasant situations, such as MassProperties oder Positional Representations. Some of them making sense, some not (i.e. postponing does never make sense, but some updates are comprehensible, whereas some seem completely idiotic).

The Vault doesn't care about these at all: It will gladly release anything you tell him, no matter how messed up it is. 

What you can learn from this thread is, that Autodesk doesn't care. You'll have to get your stuff straight on your own. Once you manage to do so, the amount of incomprehensible save- or edit-prompts will decrease dramatically.

If the explanation above doesn't match your described case (because my assumption that you're actually talking about an Assembly instead of a Part was wrong), there are several other possible explanations (e.g. a derived part whose source has been changed meanwhile). If you want a thorough explanation, you'd need to share some more information.

[n.schotten]

@Bert_Bimmel

Sub assemblies and parts (and deeper subs) are an issue. As library / standard parts are used and updated in one place, they cause issues when opening oter assemblies where they are also used. causing more updates, and when going back to the other assembly it triggers the update and save there too. This behaviour needs to be looked at better and a method found to not act this way.

Part of this issue might be that as fiels get saved and saved, other files have refrences to older versions. Something you'll notice when trying to purge files.

Try as i might i can't find a method to have the vault update refrences to the lates versions of all files used.

Basicaly have a tool go trough eacht part file, look at where they get used and only update the version refrence in the assembly. go through all parts and then seek out the lowest ranking sub assemblies and update the files they are used in to the latest version. All the while not changing the version numbers of the files themselves.

Migrating files does not do this. Heck, that might also make the problem worse.

Iparts and iassemblies also have issues with the saving of it's parent file. as for some reason the parent file is 'notified' of which child is in use. And thus what line in the table is active. Or so the behaviour seems to be at times.

And the Inventor developers just don't want to put 'locks' in place to just say NO to saves triggerd from assemblies for files (to be) marked as unchageable. Library parts, revision locked items etc.

[Bert_Bimmel]

@n.schotten 

Putting locks on (library)files so that they can't be saved won't help: Just consider the following simple example:

-ASM1   (Work in progress)

 + -ASM2 (released)

    +-PRT1 (released)

Lets say, ASM2 is outdated, because someone has performed some QuickChange on PRT1 causing an Update of ASM2.

If you refuse to update and save ASM2, ASM1 will never ever reach a clean state, as everytime you reopen it, ASM2 will be volatilely updated again and again, causing ASM1 to need an Update every time too.

You must get your things straight, (and be aware, that no two different versions of the same file can coexist on any client), otherwise Inventor will keep bugging you forever and ever.

[bradeneuropeArthur]

Hi @Bert_Bimmel 

Why is actually only the "Part Number" change in an child file, triggering an "BOM update required"?

Other property changes do not trigger an "BOM update required" for example:

• Description
• Stock Number

Is it not the case and true that all checks and workflows mentioned above are very time consuming and not practical for normal working conditions?

Because at the end of the day we need to have released our designs for manufacturing, and this process is delaying.

Furthermore, every mistake will lead into doing these steps/checks/updates again and again.

I cannot sell this anymore within our company and project group.

Bert, is this really the intention, to your opinion, to work this way?

Regards

[Bert_Bimmel]

@bradeneuropeArthur 

This is only a long shot, but I assume the reason why the PartNumber is special compared to all other iProps when it comes to BOM-Updates is, because you can use it to merge rows with different parts bearing identical partnumbers (classic example: two different parts both representing the same spring, one tensed and the other one relaxed, or maybe the same timing belt windind around different sets of discs, or whatever else may come to mind).

My desired way to deal on this would be if the developers would finally get up their A55E5, and stop hiding everything behind a thick layer of fog, and lead the user through everything that's mandatory to maintain a clean set of data. but unless they don't (and as we all know they won't), the only thing left is to find your own "modus vivendi".

As i can tell from my own experience, yes, it starts with a hell lot of work in the beginning and it might be time consuming and frustrating, but the longer you keep on disciplining yourself, the better it gets, i.e. Inventor will bug you less and less with unbidden saveprompts, as your libraries are getting cleaner and cleaner. At some point, it will reach a state where it almost only prompts you to save  only things that you have really changed.

What turned out to be helpful too (both in the beginning as well as later, when things have become better) is to ignore the vault as long as you're really working on your project. No automatic check in or check out, and especially no "opening from the vault" and let yourself be surprised what happens. just work locally and pretend the vault isn't there. If something needs saving, save it and decide later if this version needs to be uploaded to the vault. If you decide not to, replace your local copy that has been altered accidentially by the latest version from the vault before proceeding. Never check in an assembly that references a version of one of its children, that is unknown to the vault (the vault doesn't watch). Once you have reached a point that you consider worth beeing archived, do it. Your colleages which might be working on different parts of the same project will appreciate, if they don't get half baked  versions injected into their own workspace every now and then.

[mateusz]

Besides working with released components, a thing that drive me crazy is that when I try to edit in-place a PRT, Inventor automatically updates/rebuilds entire assembly as soon as I enter the PRT. It happens as well when I change order of parts in the tree (no direct modification of any part or constraint). This behavior consumes a lot time. Only solution for that is to open part/subassembly in separate window to edit it. 

[Bert_Bimmel]

Here's another idiocy i cannot believe that i never took notice before:
You cannot override the visibility of a root-Workplane of any occurrence within the current assembly without dirtying the occurrence's source when trying to do so?! Why are the visibility states of root-Workfeatures and userdefined workfeatures handled differently???

And how about enabling to toggle workplane visibilies (or associationg designviews) via API?

SetVisibilityOfOccurrences fails, if the ObjectCollection-Argument contains any Workplanes or WorkPlaneProxies, and there seems to be no other method to handle this 

[Dan_Margulius]

Guys, everything is great and lot's of opinions BUT I could not find the recommended 

workflow from Autodesk on how to solve the problem or avoid it trough correct workflow. 

I had this with Inventor 2022.4 and Vault 2022 and

now encountered the issue with Inventor 2023 and Vault 2023. 

The SAVE triggers set to NO don't really solve the problem. 

T&P cause an issue with save\check in, FG cause an issue with save\check in... LIB files maybe. 

In 2022 for sure in 2023 we did not use LIB folders and got nailed because of the TP subassy.. 

I have a case at ADSK and sent the entire 400 GB backup and I am waiting for months for a resolution. 

How is it possible to continue like that? 

Regards

Dan 

[Bert_Bimmel]

The next step:

I have an Assembly with some parts which have all been saved last with Inventor 2020.

I open it in Inventor 2024, some parts are toggled invisble (Primary ModelState active):

I click "Save, and the Save-Prompt pops up with three parts suggested for save due to Migration:

(the attentive spectator my notice, that these are the assembly and the three visble parts)

I click cancel.

Now I do NOTHING ELSE BUT hovering over one of the hidden part's browsericon with my mousepointer for a second,

and click save again, and - hokus, pokus, fidibus - that component is all of a sudden worth beeing saved too!

That you call improvement on this thread's topic???

[Favagiorgio1]

Same, a lot of wasted time.