Vault Pro 2014 and Inventor 2014 File Migrations with Task Scheduler

[swalton]

I am trying to use Task Scheduler from IV 2014 to migrate about 2000 files from various old versions of IV to IV 2014.  All files are in Vault Pro 2014.

I selected a directory in Vault and picked all IV file types with recursion to get the 2000 files.

The task runs, checks out the files, migrates them and reports that it has checked them in.  All good so far.  If I look at the task log I see a list of files checked out, some migrated, some already in the current IV version and then a list of files checked-in.  If I look at the various files with Vault Explorer while the migration task is running, I see them checked out and I see the green saved icon as the migration progresses.

However, when I look at the directory with Vault Explorer, I see that most of the files show the "edited out of turn" icon and report that the latest file is from 2010 (or whatever the last time anyone checked the file in with Inventor).  There is no evidence of any versions that the migration task should have generated.

How do I perform a migration task that actually gets the migrated files back into vault, not just sitting in my workspace?

How do I configure my migration task to get both the children of an iam and the idws of the children?  We detail each sub-component in a separate idw and they are spread out in the vault in a series of different directories.

[jdkriek]

I ran into same problem at the beginning of this year migrating 2011 files to 2014.

I had to create a seperate Check-In job for most of the migrated files on my local.

[steveh3]

For what it's worth...we have been on Vault for almost ten years starting with Inventor 5'ish. Haven't migrated a single time. Over 1.3 million files in our Vault.

Haven't had any issues that we know of.

So, is migration necessary? For us no.

[jdkriek]

Steve that may work for a system where files aren't constantly being checked out and modified/revised, but it's not ideal at all for most workflows. You would literally have to check out all files - some of our assemblies are over 1,000 parts - as Inventor will automatically migrate the file to the latest version on save which will in turn trigger a edited out of turn problem if you haven't checked them out as already mentioned. 

[steveh3]

Not sure if you are aware, there is a setting in App Options in Inventor which will allow Inventor to migrate but not prompt you for a save. This should eliminate your edited out of turn. Make sure its unchecked.

We have well over 1,000 part files too. Some, files havn't been migrated since the day we put them in (2004'ish), but still use them in 100's even 1,000's of assemblies.

We use items which lock the files down and it's impossible to migrate the file unless you have the item in a WIP state in a change order.

So, migration isn't even an option. Especially when you have well over half a million files to migrate.

I'm on the opposite side...I agree that this may not work for all cases, but as Vaults grow and files get locked down like they should, migration will nearly be impossible. 

It's worked for us for well over ten years and don't miss the days of migration, plus if we did migrate, you would be shutting our department down for at least a week which is not an option.

[swalton]

I created a separate check-in job with task scheduler.  It worked ok, except for the files that had lost their children due to renames.  Those will have to be fixed manually.  For the most part, those are concept files that are not really needed, but got picked up when I selected folders for migration.

I normally set the Prompt to Save option to checked.  That way we slowly migrate the files that we use. 

If you uncheck that option, I think IV migrates the files each time you open them, but doesn't save the changes.  That's ok, but it seems like a lot of repeated work for the computer.  Do you see a slowdown opening old un-migrated files versus new files of similar size?

I have never understood why Vault did not ship with a migrate job and permissions to handle released files in the background over a few weeks.  That seems like a good use of the Job Processer.  

[swalton]

@jdkriek:

I didn't accept your reply as the solution, because it is a workaround. The Migrate from Vault task should handle this better than it does.

I did Kudo it because it is a functional workaround.

[jdkriek]

---

@swalton wrote:

@jdkriek:

I didn't accept your reply as the solution, because it is a workaround. The Migrate from Vault task should handle this better than it does.

I did Kudo it because it is a functional workaround.

---

I understand where you are coming from, but personally I don't penalize people for workarounds, especially when it's the only method of completing the task.

[steveh3]

swalton wrote:

"If you uncheck that option, I think IV migrates the files each time you open them, but doesn't save the changes.  That's ok, but it seems like a lot of repeated work for the computer.  Do you see a slowdown opening old un-migrated files versus new files of similar size?"

______

Yes, you are correct, the machine has to migrate everytime, but we really don't notice much of a slow down outside of a few seconds. The alternative is to allow the migrated files to keep happening, keep checking them into Vault and get revision-leveled to death. When you start dealing with release states, adds a whole other level of complication.We would be constantly running rev bumps for no benefit to anyone in the company with the exception of gettting the files to the latest release. A few seconds of engineering waiting, far outweighs the rest of the company reviewing a change which really didn't change anything.

I agree, needs to be a better way on how to bring them up to the latest release.

Thanks for the insight guys!!!