Question
Windchill Update Behavior
I have recently run into a situation where an later version on an CAD document (Pro/e assembly) was inadvertently overwritten by an older version of that same document. After much investigation I was able to determine that the default workspace update functionality doesn't actually replace the local file contents during an update, it only updates the metadata to make it look like you have the latest version. For those who would like a detailed explanation of the tests I performed, and the behavior experienced, I have listed it all in detail below. For those want to get right to the question, here it is. Is there a way to configure either Windchill or Pro/e so that a "File", "Update" command from Pro/e functions the same way the workspace "File", "Update" command does from the workspace when the site preference "Update Overwrite Local Content" is set to "Yes"?
Tom Uminn
Engineering Systems Analyst
trans-matic Mfg.
616-820-2499
-<">mailto:->
Test Results - All from the local workspace (embedded browser). Tests were initially run with the site preference "Update Overwrite Local Content" set to "No".
Test 1 - Unmodified, out of date, update from workspace (works as I would expect)
1. Have unmodified, out of date object in the workspace, and open in Pro/e.
2. From the workspace webpage, select the object and choose "File", "Update".
3. The "Update" page default action is to download the object. Choose "OK".
4. Latest version of the object is download from the server. Object in workspace remains unmodified.
5. A "Replace in Session" dialog opens asking you if you want to replace the object currently in session. Choosing yes replaces the object that was in session with the one that was just downloaded from the server.
Test 2 - Unmodified, out of date, update from Pro/e (works as I would expect)
1. Have unmodified, out of date object in the workspace, and open in Pro/e.
2. From the Pro/e "File" menu, choose "File", "Update", "Current".
3. A "Update in Workspace" dialog box opens asking if you want to replace the object in the workspace with one from the server. Choose "Yes".
4. A "Replace in Session" dialog then opens asking you if you want to replace the object currently in session with what is in the workspace. Choose "Yes."
5. At this point both what is in session and what is in the workspace are both the latest, unmodified version of the object.
Test 3 - Modified, out of date, update from workspace (does NOT work as I would expect)
1. Have a modified, out of date object in the workspace, and open in Pro/e.
2. From the workspace webpage, select the object and choose "File", "Update".
3. The "Update" page default action is to reuse the object. Choose "OK".
4. The metadata from the latest version on the server is synchronized with the workspace data, now indicating that you have the latest local version in your workspace. However it is still shown as modified, and is never replaced in session (because "reuse" was chosen in step 3).
Test 4 - Modified, out of date, update from Pro/e (does NOT work as I would expect)
1. Have a modified, out of date object in the workspace, and open in Pro/e.
2. From the Pro/e "File" menu, choose "File", "Update", "Current".
3. A "Update in Workspace" dialog box opens asking if you want to replace the object in the workspace with one from the server. Choose "Yes".
4. Two messages are written to the information area in the Pro/e window
* Update operation performed on locally modified downloaded objects. Please use "Download" command to bring the corresponding file.
* All the objects in session are up to date.
5. As in test 3, the metadata from the latest version on the server was synchronized with the workspace data, again indicating that the latest local version is now in the workspace. But, just like in test 3, a download never occurred and therefore the data in the Pro/e session is never updated. The workspace continues to show the object as modified. At this point, one can upload their locally modified data (a modified old version) and overwrite the latest version on the server, completely overwriting any changes that were made in the versions between the version that was started with in the workspace and the latest version on the server.
While technically the software works as expected in test 3 (since "Reuse" is shown as the update option), test 4 does not say it's going to reuse the out of date data in the workspace, it just does it, and you're left assuming that you're now working on the latest version of the object. The site preference "Update Overwrite Local Content" can be used to change the default behavior when updating objects that are out of date in the workspace AND modified locally. By setting this to "Yes", the default action becomes "Download" instead of "Reuse". With this set to "Yes", test 3 then functions just like test 1 (because "Download" becomes the default update option instead of "Reuse). The problem is, this preference doesn't change the update behavior within Pro/e. Even with this option set to "Yes", Pro/e does not actually download the newer object to the workspace or update it in session. It just throws the "Update operation performed on locally modified downloaded objects. Please use "Download" command to bring the corresponding file" message followed by the "All the objects in session are up to date" message on the information area in Pro/e. The last message is the one that really bothers me. The object is session is NOT up to date. Maybe the metadata is, but the geometry certainly isn't. Any ideas? Thanks.
Tom Uminn
Engineering Systems Analyst
trans-matic Mfg.
616-820-2499
-<">mailto:->
Test Results - All from the local workspace (embedded browser). Tests were initially run with the site preference "Update Overwrite Local Content" set to "No".
Test 1 - Unmodified, out of date, update from workspace (works as I would expect)
1. Have unmodified, out of date object in the workspace, and open in Pro/e.
2. From the workspace webpage, select the object and choose "File", "Update".
3. The "Update" page default action is to download the object. Choose "OK".
4. Latest version of the object is download from the server. Object in workspace remains unmodified.
5. A "Replace in Session" dialog opens asking you if you want to replace the object currently in session. Choosing yes replaces the object that was in session with the one that was just downloaded from the server.
Test 2 - Unmodified, out of date, update from Pro/e (works as I would expect)
1. Have unmodified, out of date object in the workspace, and open in Pro/e.
2. From the Pro/e "File" menu, choose "File", "Update", "Current".
3. A "Update in Workspace" dialog box opens asking if you want to replace the object in the workspace with one from the server. Choose "Yes".
4. A "Replace in Session" dialog then opens asking you if you want to replace the object currently in session with what is in the workspace. Choose "Yes."
5. At this point both what is in session and what is in the workspace are both the latest, unmodified version of the object.
Test 3 - Modified, out of date, update from workspace (does NOT work as I would expect)
1. Have a modified, out of date object in the workspace, and open in Pro/e.
2. From the workspace webpage, select the object and choose "File", "Update".
3. The "Update" page default action is to reuse the object. Choose "OK".
4. The metadata from the latest version on the server is synchronized with the workspace data, now indicating that you have the latest local version in your workspace. However it is still shown as modified, and is never replaced in session (because "reuse" was chosen in step 3).
Test 4 - Modified, out of date, update from Pro/e (does NOT work as I would expect)
1. Have a modified, out of date object in the workspace, and open in Pro/e.
2. From the Pro/e "File" menu, choose "File", "Update", "Current".
3. A "Update in Workspace" dialog box opens asking if you want to replace the object in the workspace with one from the server. Choose "Yes".
4. Two messages are written to the information area in the Pro/e window
* Update operation performed on locally modified downloaded objects. Please use "Download" command to bring the corresponding file.
* All the objects in session are up to date.
5. As in test 3, the metadata from the latest version on the server was synchronized with the workspace data, again indicating that the latest local version is now in the workspace. But, just like in test 3, a download never occurred and therefore the data in the Pro/e session is never updated. The workspace continues to show the object as modified. At this point, one can upload their locally modified data (a modified old version) and overwrite the latest version on the server, completely overwriting any changes that were made in the versions between the version that was started with in the workspace and the latest version on the server.
While technically the software works as expected in test 3 (since "Reuse" is shown as the update option), test 4 does not say it's going to reuse the out of date data in the workspace, it just does it, and you're left assuming that you're now working on the latest version of the object. The site preference "Update Overwrite Local Content" can be used to change the default behavior when updating objects that are out of date in the workspace AND modified locally. By setting this to "Yes", the default action becomes "Download" instead of "Reuse". With this set to "Yes", test 3 then functions just like test 1 (because "Download" becomes the default update option instead of "Reuse). The problem is, this preference doesn't change the update behavior within Pro/e. Even with this option set to "Yes", Pro/e does not actually download the newer object to the workspace or update it in session. It just throws the "Update operation performed on locally modified downloaded objects. Please use "Download" command to bring the corresponding file" message followed by the "All the objects in session are up to date" message on the information area in Pro/e. The last message is the one that really bothers me. The object is session is NOT up to date. Maybe the metadata is, but the geometry certainly isn't. Any ideas? Thanks.