Problem with Inventor & Vault basic

[edarlak]

We are having an issue at our company with Inventor iam/ipt revision control via the vault.

Some of our users are getting their latest assemblies overwritten in the vault by older assemblies when some users open an iam off of their HD and then check out the assembly, and then subsequently check it back in.  During this process, vault is not getting the latest version, it just checks out the assembly that was on the HD and makes that the latets version, this seems contrary to the point of having a vault store?  How do I force an automatic refresh from vault before someone checks out an assembly? 

Asking people to resfresh from vault doesn't always work, as 1) they forget to do it sometimes, 2) sometimes refresh doesn't work, we have to actually delete the old iam off the HD before vault will put the new iam on their HD.

Also, deleting files off the HD upon check in is not an option for us, even though we have our vault backup every night, some of us like to have the "personal backup" of the files on our HD as well.

Why does vault/inventor allow an older iam/ipt become the latest vault version anyways, how do I disallow this?

Does vault basic include workspace sync?

[karthur1]

---

@edarlak wrote:

We are having an issue at our company with Inventor iam/ipt revision control via the vault.

Some of our users are getting their latest assemblies overwritten in the vault by older assemblies when some users open an iam off of their HD and then check out the assembly, and then subsequently check it back in.  During this process, vault is not getting the latest version, it just checks out the assembly that was on the HD and makes that the latets version....

---

Mostly what you are talking about is a discipline thing. If there are several people working on a project, they have to be aware that others are changing files.  Before they check out files they need to be aware and check the vault browser in Inventor to make sure they dont have a red dot there.  What version are you using?

1. Vault Basic does not control "revisions".... only file versions.

2. "it just checks out the assembly that was on the HD and makes that the latets version".  Vault does not do this.  It is not made the latest version until the user checks the out-of-date file into vault.

---

@edarlak wrote:

....

Asking people to resfresh from vault doesn't always work, as 1) they forget to do it sometimes, 2) sometimes refresh doesn't work, we have to actually delete the old iam off the HD before vault will put the new iam on their HD.

---

"sometimes refresh doesn't work, we have to actually delete the old iam off the HD before vault will put the new iam on their HD..." I could see this happen if the files were in use when you tried to do a refresh from Vault... or maybe your workspace is not mapped correctly and vault is putting the files some place besides where you are expecting them to be written.  One thing that might help is show the local folder (Tools>Options, Show working folder location).

@edarlak wrote:

..... 

Also, deleting files off the HD upon check in is not an option for us, even though we have our vault backup every night, some of us like to have the "personal backup" of the files on our HD as well.

Why does vault/inventor allow an older iam/ipt become the latest vault version anyways, how do I disallow this?

Does vault basic include workspace sync?

---

I don't delete the files upon check-in either. Its a pain when you have multiple assemblies (or idws) open that all share parts.  In Vault 2015, I have read there is some improvements in this area, but I am not sure if they are included in Vault Basic.

Read about what new in 2015 here.

I am installing VB 2015 as I am writing this.

Kirk

[gandhey]

Hello,

Yes as per earlier comment - this is really a discipline thing.

Please note that users are indicated with a icon/also a tooltip that the file is 'Out Of date' in Vault Browser in Inventor. So may be asking users to use Vault Browser while working in Inventor will help identify the out of date files easily.

And Vault Basic donot support Workspace Synchronization.

Regards,

Yogeshwar

[edarlak]

"What version are you using?"

We are using Vault Basic 2014.

"I could see this happen if the files were in use when you tried to do a refresh from Vault... or maybe your workspace is not mapped correctly and vault is putting the files some place besides where you are expecting them to be written."

Workspaces is definitely mapped correctly when we have this issue.

[mikel_martin]

What would your preffered behavior be?

Would you want to block the ability to checkout previous versions?

When would you like the files to be updated?

Assuming we can do anything you ask (hypothetically).

I would like to get multiple opinions on this.

[edarlak]

"What would your preffered behavior be?"

I would prefer that when a user opens a file (.ipt or .iam and all of it's children) from his/her HD that is not the the latest version in the vault, upon checkout, their local workspace file(s) are all auto refreshed.  Basically acting like workspace sync on demand/usage.  No dialog boxes that people get sick of and fly past not paying attention to what they are clicking, no browser bar manual refresh, etc.  A vault admin option that forces a users workspace to be transparently auto refreshed upon checkout of any part/assembly they have opened from their HD.  If my company had such an option, our issues would be resolved.  However, this may not be what all companies/vault admins want.  So having this as an administrative tool (checkbox) might be the best way to implement it.

The more dialog boxes you give users to make decisions, the more likely they screw it up.  I want to make this "snyc on demand" as transparent to the user as possible.

[karthur1]

It is just too easy for the user to check out an older version. If the files were automatically refreshed when we opened a file that was out of date, then there would be no way of opening/viewing an older vaulted version.

Since vault already knows that the local version is out-of-date (it shows the red dot), I think it would be best to prompt the user as to what to do when they try to edit the out-of-date local copy. There could be a dialog that comes up to tell the user that the local copy is not the latest, then give them a choice to 1. refresh the local copy and check it out, 2. check out the out of date version, 3. cancel the command and do nothing. Of coarse, there needs to be a way to suppress this dialog so people that do not want it can work like they have been in the past.

I know that this is another dialog/prompt that gets in the way, but this is better than overwriting the latest version.

Kirk

[mikel_martin]

So what I am hearing is...

I want the file to auto-refresh, except when I dont want it.

I need a way to open historical versions.

I need a way to revert an old version to the latest.

What if....

The default behavior was to always auto-refresh files on open.

There was a method to "pin" a local file to a specific version.

There was a seperate command to revert a old version to the latest.

Would that be better?

[edarlak]

"The default behavior was to always auto-refresh files on open."

An admin option for the vault to operate this way is certainly what I would prefer.  I don't subscribe to the more dialog boxes solution.

If we need to get an older version out of the vault (which is a lot less likely than getting the latest version), we can use the copy design feature alrerady in vault expolorer.

[karthur1]

---

@mikel_martin wrote:

....

What if....

The default behavior was to always auto-refresh files on open.

There was a method to "pin" a local file to a specific version.

There was a seperate command to revert a old version to the latest.

Would that be better?

---

Auto-refresh... That would work if only one person at a time was working on a project, which is rarely the case for us  Say I have an assembly open and it auto-refreshed so I now have the latest parts. Unknown to me, you also have the assembly open.  After I opened it up, you checked out some of the files from your workstation saved them and checked them in.  Now, I want to make some changes to the same files you just checked in.  My browser would show that my files are current (unless I MANUALLY refresh the vault browser). Now if I check them out, edit and check back in, I will overwrite the files that you just checked in.

I think that when the user checks out the file for edit..... at that time there has to be a check to see if the file is out-of-date or not.  If it is, then it should prompt the user as to what to do (like I said in my other post above). Otherwise, working with a group of users that are working on the same project, there is no way of knowing that you have the latest or not. If the user blows past the prompt without reading it.....and checks it out anyway... then, there is not much anyone can do at that point. Discipline.

"Pin" a local file... sounds like it has to be done manually. Have to know more about how that would be done and cleared later.

"seperate command to revert a old version to latest"..... I have always thought there should be a Vault command to do that, rather than forcing the user to open the previous version in Inventor and then check-in the prior version.

Kirk

PS.  There are many threads here about this issue on this forum.  No simple, one line solution will exist or this would have been solved already.  One such post that I remember.

[edarlak]

"Unknown to me, you also have the assembly open"

If you have it checked out, I can't change any of your parts, this is how it's supposed to work.  In our office, if I have an assembly open, and another user needs to modify a part in my assembly, he askes me to check back in that single part, and I oblige.  If I did not check out any of the children of the assembly, then I am allowing the children of that assembly to be modified at will by my coworkers.  This part of vault operation has worked well for us.

"After I opened it up, you checked out some of the files from your workstation saved them and checked them in."

Then this means you did not check out all of the children like you should have if you can't have any of them changing on you while you do your assembly work.

"Now, I want to make some changes to the same files you just checked in.  My browser would show that my files are current (unless I MANUALLY refresh the vault browser). Now if I check them out, edit and check back in, I will overwrite the files that you just checked in."

The vault is a live connection to the DB afaik, your browser should show that those files in your workspace are out of date without you having to manually refresh, if not, then Autodesk needs to do a better job with thier DB file discovery system.  I mean they have concurrent design...

For our office, having the admin option I ask for would work for us.  The reason I ask for it to be an option (checkbox) is because yes, that may not work for every office.  I am the vault admin here and preside over only 15 Inventor workstations, and we make one-off machine tools for the aerospace industry where we don't have more than 1-2 people working on a design at a given time. 

The problem I have with the current way vault operates is my initial compliant, and we do not always catch the errors because as I said the machines are generally one-off, so it may be years before soemone goes to use an assembly as a deign reference and finds out it has been saved as an older version.

So, if I could get that option, I'd choose the auto-refresh upon checkout and force that on our 15 users. 

[mikel_martin]

Lets assume that I have magical powers, and could fix the stale status issue, and update on checkout issue.

The real question is; do you always want the latest file to just be there, when you access it for any reason?

[edarlak]

"The real question is; do you always want the latest file to just be there, when you access it for any reason?"

In my office, yes, absolutely.  There should be no reason anyone is working with an older version of a part or assembly by default.  If they need to revert due to a design error, then they either go get the file from their old versions folder or use copy design from the vault explorer.  Basically, in my office having to revert to an older version is an oops, and not a daily occurance.

[karthur1]

---

@mikel_martin wrote:

Lets assume that I have magical powers, and could fix the stale status issue, and update on checkout issue.

The real question is; do you always want the latest file to just be there, when you access it for any reason?

---

Absolutely, Yes, to that.  99% of the time we want our local files to be up-to-date with what is currently checked into vault.  The other 1% is if we need to look at an older version.

Kirk