For some reason we have discovered one assembly in our database that refuses to open with the latest iteration in Windchill. We can add the latest iteration to our workspace or by opening directly from Creo and as it's opening it does display the latest iteration then it changes to an older one at the end of the opening stage. When the older iteration is opened the workspace doesn't seem to recognize anything as being out of date.
When you synchronize the workspace, it suddenly realizes it should be the newer iteration and displays that way in Creo and all sub assembly parts update to the proper iterations as well, but as soon as we regenerate in Creo it snaps back to the older iterations.
This is has been shown to be happening with a few people opening this same model.
Are you working in a clean workspace with only that assembly in it?
Is this assembly made up of other sub-asssemblies or just piece parts?
Yep, brand new workspace, nothing else in there.
The assembly has a number of sub assemblies and piece parts assembled in it.
Thus far haven't discovered this problem with any lower levels within this assembly. If we open those first they will open with the proper iteration.
I did try opening as many sub models as I could to try to force Creo to keep the proper iterations in memory and check the top level back in and it still continues to revert.
Bouncing off of what @BenLoosli said, maybe shut down Creo and temporarily create an entirely new local cache. Re-register the server, add the files to the workspace, and then try again.
How do you know for sure you're actually seeing an older version of the assembly? If you go to 'Tools', 'Investigate', 'File History', does the last save date in Creo match what is shown in Windchill?
The version in file history is listed as the old version.
The dates/times for upload all match the dates to the newer iterations in our database.
This model isn't something I worked on until we ran the problem was discovered and started trying to solve it, so I really shouldn't have had it anywhere on my machine.
The user that found the problem had gone through the steps of new workspace, deleting the old one, and even deleting the .wf folder to try to ensure no cache exists and they had the same issue. I could try going to the ultimate extreme of deleting every possible cache/history item I can think of and give that a shot though.
Deleted everything I could think of to get rid of any cache possibilities and the problem remains.
I decided to then try opening the iteration it keeps reverting back to as-stored and discovered that even that iteration seems to point to the previous one.
I had to go back another 5 iterations before Creo and Windchill seemed to agree. Of course there are no check in comments for any of these iterations to try to understand what they might have been doing.
Do you have access to tech support? It would be really interesting to understand what's going on here. If Windchill is offline, it should be physically impossible for any earlier files to be pulled from Windchill. Something else seems to be going on. This assembly is not part of a family table, is it?
Yes, I believe we do have tech support access, I haven't ever gone that route. Will ask our official admin to ask for their help.
It doesn't seem like the geometry is out of date, changes seem to reflect the latest iteration. Just that Creo and Windchill can't seem to agree what iteration they are looking at.
No family table involved.
Normally Creo will always default to Windchill first, but maybe it's worth checking to see if this assembly file is in any of your Creo search paths, your startup directory, your working directory, the 'My Documents' folder, or your home folder (if different.) Make 100% sure there is not another copy of this somewhere.
I tried exporting the workspace to a local folder and opening from there. Still reverts back to the old iteration.
I tried opening that exported local version in notepad and there were a few iteration references to the old number, nothing in there matched the newer iterations. I can however find some mentions of the first iteration this model seemed to be acting up on.
We never got resolution. Our main admin was going to contact PTC support but when trying to generate a trail file they said they couldn't replicate the problem. I have tried following up a few times and it seemed to still be happening, but I think there have been other issues taking priority.