cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

We are happy to announce the new Windchill Customization board! Learn more.

So, why doesn't "update" actually WORK?

Patriot_1776
22-Sapphire II

So, why doesn't "update" actually WORK?

I have "dm_overwrite_contents_on_update" set to "yes", and an overwrite in Intralink worked just fine, every time......yet now in W/C update doesn't actually do anything? Huh?

56 REPLIES 56

That is certainly part of what causes the pain Celia was referring to earlier.

I wonder what the results of the CAD Data Management Diary Study were (http://communities.ptc.com/thread/36806)

LoriSood
22-Sapphire II
(To:mmontgomery-2)

Hi Marc.

You mentioned earlier that you have "Reuse Modfied Workspace Content" preference set to No under the "Add to Workspace and Check Out" preferences. What context is that set in (e.g. Site, Organization, Product)? If you lock the preference at the Site level in Preference Management does that make any difference? If I perform an Add to Workspace on a modified file in my workspace then it recognizes what I have set for that preference.

Are you performing an Update or an Add to Workspace? If the former then that preference will not apply. It doesn't look like there is a preference that controls this behavior for Update. It looks like it will always default to Reuse if the files are modified in the workspace when performing this via Creo. The options to reuse, download, or link are not available in the standalone browser because those options don't apply since it doesn't deal with the workspace local cache, and, therefore, the physical Creo files--essentially, the standalone browser handles metadata for CAD Documents. That's why there is a difference in this case depending on where the action is performed.

All,

Thanks for your comments. I now understand that the settings I changed initially pertain to the "add to workspace" function whereas I wanted to adjust the "update" function. Rookie mistake. I think I've now figured out what I wanted to do. In the version of WC were running (10.2 Essentials), when I update my workspace, all of my locally modified content is uploaded to the server and I can see the changes in workspace status in a standalone browser. After digging a bit more, I found the following setting and changed it to 'Yes':

update preference.JPG

Originally, the default in creo embedded browser to update was to REUSE the modified content, noted by the recycle symbol:

creo update 1.JPG

However, after changing "update overwrite local content" to "yes", the default action then changed to download from server, notice the change from recycle symbol to download symbol. This again is in the embedded creo browser after the parameter change:

creo update 2.JPG

Now you can see that download is the default action and there is a yellow triangle next to it, this is a warning message that modified content will be overwritten.

Note that in both cases, there are toolbar options (highlighted) to change the action to 'download' or 'reuse', all that is changing is the default action on update.

As I discussed previously, the default standalone browser action is still to download by default which is what I want:

firefox update 1.JPG

I'm still testing this so if I find any issues I will post those later on.

Marc

In 10.2 you are able to upload content, that is not checked out. This is new.

Since then it is not possible to overwrite locally modified content in the way you described.

Because updating essentially transfers the file from the server-side workspace to the local workspace-cache. And both are modified...

So in order to restore the original file in your workspace, you would actually have to delete it there, search it in commonspace and add it back to the workspace again.

There is room for improvement, I'd say.

Of course, if you do not upload, then it's the same behaviour as in 10.1 and earlier.

TomU
23-Emerald IV
(To:HerwigSchwarz)

Instead of update, use the "+" sign to re-add the content to the workspace.  This will overwrite any uploaded changes.

No, it won't. The green + is the button I was talking about. Sorry that I called it "Update".

Go on, try for yourself! Change some part in Creo, override the conflict with "Continue", save it and upload it to the server-side workspace.

CS172371 titled “Windchill PDMlink 10.2: Add to Workspace from within workspace and uncheck "Reuse modified workspace content" does not download the former content file from common space”.  https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS172371


The above preference change resolved the issue here.


  1. Quick Links (in the upper right) > My Settings > Preferences
  2. Display> Configuration Specification> Apply Configuration Specification to the originally selected object
  3. Right click on the word NO and select SET PREFERENCE
  4. Change the value to YES

You can also manually set this via the EDIT FILTERS when updating the objects.  There is a check box in the filters dialog.

Hope that helps.

Regards,

DN

Alright, this works! Thank you!

I tried this setting with high hopes......and it did NOTHING.  I'm pretty upset.

So, since Windburn does NOT work the way it should, the way any reasonable person would expect, and or the way it USED to work in Intralink (a far superior vaulting system), my advice is:     For everything marked as "Out of Date" in your Workspace, DELETE it, and then add it again.  A HUGE waste of time.  That's the ONLY way you can be sure of actually GETTING updated models....instead of the HAL9000 system simply telling you it's all up to date.....and it not be.  A very dangerous situation.

Caveat emptor....

Oh, and my company is thinking about implementing this disaster company-wide, and I'm going to advise them to find something else and re-migrate the data to whatever else is an option.

dnordin
15-Moonstone
(To:Patriot_1776)

Frank,

  The "fix" I listed above was specific to "re-adding" the commonspace version of a model that is locally modified in the users WS, uploaded, but not checked out.  This is specific to 10.2.  I was answering Herwig's questions/issues.

 

  We've never had any issues with users updating out-of-date (non-latest) models in their WS.  We only run the update command from within the embedded browser in Creo Parametric.

 

Regards,

DN

Patriot_1776
22-Sapphire II
(To:dnordin)

I did a couple tests.

Test 1:

1.  Changed that setting.

2.  Modified a model.

3.  Did an update from within Pro/E - it worked.

Test 2:

1.  Changed that setting.

2.  Modified a model.

3.  SAVED that model.

4.  Did an update from within Pro/E - it did NOT work.

Test 3:

1.  Changed that setting.

2.  Modified a model.

3.  SAVED that model.

4.  Did an update from within Windchill - it did NOT work.

If that setting was valuable, it would have worked in tests 2 and 3.  I expect users to save their models after significant changes.  Update SHOULD work after a save, as long as a user has not checked-in their model.  This is obviously not the case.  I'd have to say "Update" is a pretty epic FAIL.  Why would PTC make a command that only worked 1/3 the time????

Like I said, I've told my users to delete files and re-add them.  HUGE time-waster.  I've told management of this limitation as well.  They're not happy either.  All the users HATE it.

Do you have save and upload enabled or is just a plain save to your client side workspace?

Patriot_1776
22-Sapphire II
(To:BenLoosli)

I'm not 100% sure.  The Windburn variable "Upload After Native Save" is set to "yes", and from the description, it seems like that covers it.  I'm ok with that action, what I do NOT want is every "Save" doing an automatic "Check In"!

dnordin
15-Moonstone
(To:Patriot_1776)

Frank,

Thanks for listing what you did for your tests.  Some comments:

Definition:  Out-of-date means that the Windchill Version [revision.iteration] in the CS is at a higher level than what you have in your WS.  For example: A.5 in the CS vs. A.4 in your WS. 

NOTE: If you have A.5+ in your WS, this is NOT considered out-of-date by WC as the versions are still the same, only the model content is different in your WS (your working copy).

Test 1.

The modified model is in session only, so your WS model is different than what you have in session.  The "update" command within Creo Parametric is going to replace the in session model (which is modified) with the WS copy of the model.  It did NOT replace your in session model with what is in the CS, but rather with the WS model.

Test 2.

After you saved the model, the in session model is identical to your WS model.  The update within Creo Parametric will no nothing as the models are not out-of-date.  Are you expecting the "update" command within Creo Parametric to download the CS model and replace your modified model both in your WS and in session?  The update command will only do this if someone else has checked in the same model [Version A.5 in CS], and now your model is out-of-date both in your WS and in session [Version A.4+].

Test 3.

After you saved the model, the in session model is identical to your WS model.  The "update" command within the Creo Parametric embedded browser will do nothing as your model (both in the CS and in session) is not considered out-of-date.  (i.e. the WC versions [revision.iteration] are identical between the CS model and your modified version of the model in your WS)  For example: If you downloaded version A.5, your WS version is still A.5 (albeit with a +).  Only the content has been modified, not the WC version.  The update command in the embedded browser will only work if your model is out-of-date which yours is not.

If your intent is to retrieve the CS copy of a model [Version A.5 in CS] that you have locally modified in your WS [Version A.5+], you need to use the ADD command, not the update command.  There is no "Add" command inside of Creo Parametric.  You need to use ADD from the embedded browser.  The preference I stated in the earlier post will allow you to retrieve the CS copy of the model when you have a locally modified copy that has been saved, uploaded, but not checked out (WC 10.2+).  Once you have "re-added" the CS model to your WS, you can update the model in session as well.

Regards,

DN

Patriot_1776
22-Sapphire II
(To:dnordin)

....except that "Add" doesn't seem to work with any consistency either.  I've found that only deleting the offending files, and re-adding them (see my comments about being a HUGE waste of time) seem to work 100%.  THAT, is my issue.  I don't trust this software.  At ALL.  I'm never sure of anything it does.  sigh......

"Add" does work with consistency if you set the preference that Daniel Nordin has described above, answering my question.

Funny, I haven't had it work with any consistency.  I'm still going to advise deletion and a re-add as the only way to be sure.  If windburn considers the model with changed geometry the same as the model with the older geometry simply because of a setting or the same "version", then that's simply another reason for me not to trust the software.  I mean, that logic on PTC's part is simply absurd.

dnordin
15-Moonstone
(To:Patriot_1776)

Frank,

Regarding your statement: "If windburn considers the model with changed geometry the same as the model with the older geometry simply because of a setting or the same "version", then that's simply another reason for me not to trust the software.  I mean, that logic on PTC's part is simply absurd."

WC does NOT consider the model in your WS marked with a + the same as the CS copy.  The version [revision.iteration] listed in your WS is showing you what version of the CS model you originally added to your WS, nothing more; it is not an indicator of any local modification to the model.  The "+" in your WS status column (usually titled Modified Status) indicates that you've locally modified the file.  The "Out of Date" status column in your WS is intended to indicate that the CS version you originally added to your WS, whether you've since modified the model or not, is no longer the latest version in the CS, nothing more.  Again, it is not an indicator of any local model modifications.

Your WS is your private space that contains your working copies of models that no one else can see.  Within that private space, the only indicator you have as to whether you have changed the model from it's original CS copy, is the "+".  Again the version listed in your WS is a reference only to what CS version you added to your WS.  There is no indicator in the table display to tell you how many times you modified and saved your working copy.

We currently use 5 columns in our default WS display table to show statuses: Modified Status, Local WS Status, General Status, Compare Status, and Out of Date Status.  Depending on the different status combinations, our users have to decide which function/action to use to accomplish the task at hand.  UPDATE will work with some status combinations, while ADD is needed for others.  We created a small help document with a simple matrix of status vs. function/action for the most common situations.  One of the reasons we did this was because of the confusion between the ADD and UPDATE commands coming from the old 3.x days of Pro/Intralink.  Once our users referenced the document a few times, they learned quickly what they need to do based on the status icon combinations in the columns we display.

If you search the WC help pages for "About Object Status", there are some definitions/explainations of the status columns.

Regards,

DN

TomU
23-Emerald IV
(To:dnordin)

We created a small help document with a simple matrix of status vs. function/action for the most common situations.

Would you have any interest in posting this (or a picture of it) for the benefit of others?

Patriot_1776
22-Sapphire II
(To:dnordin)

I've got all those columns too.  It's too much of a pain for me or my users to try and decipher something that should be dead simple.  Most of my users are x-Solidworks guys, and only part-time Windburn users at best.  I can't expect them to have to decipher this maddengly complex and absurd matrix when they shouldn't have to, and even I can;t remember what conditions equal what.  So, mistakes are made, and then I have to listen to them rightfully complain about what a PITA it and/or Pro/E is, and then I have to clean it all up.  So, Delete, and re-add ALWAYS works, though it's a huge time-waster if there are a lot of files.  i much prefer this to mistakes though.

"Update" should be just that.  When I drag and drop a file in Windows, it does exactly that, no BS.  That's what I expect.  I seem to remember that's exactly how it worked in Intralink, the much superior software they forced us to not be able to use again.

I appreciate your comments, don't get me wrong, but it reinforces my distrust and hatred of the software, because it seems NOBODY can get it to work effectively.

Frank,

When we first went to Windchill our tried and true process was to remove modifed objects from the workspace as it was the most reliable method!  But, after 6 years we have learned how to efficiently interact with WC.  Here is my proposal and recommendation: 

1) Update - Use Update once per day before the user starts working to find and update objects that other users have changed to ensure they are working with the latest content.  Do not use update when Objects are in Creo Session...if a large assembly, then WC wants to download required dependents of the assembly.  In our case, large assembly = 100,000+ objects.

2) Add - In Windchill Environment, the goal is to avoid the Add function as much as possible.  We have our collector settings at None for Dependent cad documents on add to workspace.  I have done lots of time testing and found out that it takes less total time when letting Creo open and download the necessary components.  (File -> Open in Creo and type in the assemlby/drawing name without any objects in the workspace VS.  Add required dependents and then open in Creo.)

3) Check-Out - Train the users to interact with the conflict pop-up in Creo.  Example - Use continue for the family tables that get marked as modified unintentionally, then check-out when an intentional change is planned for.

4) Check-In - Train the users to check-in from Creo.  We have the collector settings at Required for dependent cad documents. Only the checked out items in the check-in table will be checked in and if necessary you can check-out lower level dependents in the table on the fly if needed...it ignores all the modifed items in the list.  With this logic, you can reduce the time the user goes to the workspace to refresh table, add or remove items. Tthere is obviously a risk to this process....thus due dilligence is required to check-out the items that are intentionally modified.

5) Remove - The primary reason to use remove is to reduce the objects in cache to get performance back in our environment.  We have found out that deleting a workspace and creating a new one ensures good performance over the long run.

We are still in WC10.1 and anxious to test the autoupload functionality to the server side workspace when going to WC10.2.  We were not able to utilize it in WC10.1.  

Patriot_1776
22-Sapphire II
(To:BillRyan)

Thanks for the tips Bill!

In config.pro you should have dm_upload_objects set to automatic.

Not sure what the difference is between the Windchill and Creo setttings.

Patriot_1776
22-Sapphire II
(To:BenLoosli)

...exactly part of the problem.  WAY too complicated and incomprehensible...... 

BenLoosli
23-Emerald II
(To:BenLoosli)

Frank,

Contacted PTC for difference between the two settings and this was their response: "The only difference between the two is that setting upload after native save is used only for 3rd party CAD software. Creo does not recognize this setting."

You should set the dm_upload_objects  to automatic in your config.pro.

Top Tags