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?
We ended up doing an "Add to Workspace", and choosing NOT to reuse the file did the trick. However, this is still puzzling, why doesn't Update work?
I agree with you Frank -
The bestg thing you can do is "Add to Workspace" and unchecking the "Reuse Content from Target Workspace". It actually gives you flexibility in case if you want to keep your workspace changes.
The definition of the Update action in Windchill differs from Pro/INTRALINK. In Windchill you use the Update action in order to update out-of-date objects, i.e. retrieve a later version of an object to the workspace from commonspace. E.g. you have version 1.4 (A.4) in the workspace and there's a 1.5 (A.5) version in commonspace. The Update action will overwrite the 1.4 version with the 1.5 version. With the dm_overwrite_contents_on_update preference you can set the default behaviour when you have modified the 1.4 version using continue. If it is set to Yes you will overwrite the modification made to the 1.4 version. If it is set to No you will keep your changes but they will have been made to the 1.5 version. E.g if the 1.4 version is a simple extrude. You have modified the 1.4 version using continue, adding a hole.The 1.5 version contains the simple extrude and a round. If you use Update and have the dm_overwrite_contents_on_update preference set to No you would have the 1.5 version in the workspace with the extrude and the hole without the round (i.e. you have overwitten whats in the commonspace). If you check it out and check it in the 1.5 version would be the extrude+hole and not the extrude+round.
The action to overwrite modified content in the workspace (made by you) is Add (read Add to workspace). E.g. you have the 1.4 version in the workspace and you have made modifications to it using continue. You can deselect the Reuse content in target workspace or go to the Advanced tab, select the objects and click Download. I would suggest that you go to the Advanced tab so that you can decide what objects to overwrite and what objects to reuse. E.g. if you use the Add action on an assembly the dependencies set to required will overwrite all modifications made to all parts if you deselect the Reuse content in target workspace check box.
Hope this helps.
Thanks, that's helpful, but still too complicated. Still not sure I follow it actually. Honestly, I think I'll just avoid using the command, and stick to "add to workspace". The Intralink definition is so much better and simpler. You update, and it changes whatever was in your Workspace to be what's in commonspace. Simple, easy to understand. I don't see the need to completely refine terms we were all familiar with to completely reverse what they used to do. Think what would happen if the meaning of stoplight colors was reversed.
In Windchill (pdm essentials), we've been trying to change the default setting to download the latest from the commonspace however whenever I do an update it always defaults to reuse, we've set the reuse option to no as seen below:
I've done this at the coorg and wcadmin level and it persists with the default of reuse:
Is there another setting that is overriding this?
We've seen some instances where people use the "continue" option instead of "checkout" and then make some changes and save them in their workspace, they then do an update and think that all the latest and greatest has been downloaded and theyre good to go. They then check out/check in and the changes they made before checking out are then checked in. this has led to lost work and wasted time. If we could either remove the "continue" option and force a "checkout" or delete "locally modified" content, we'd be a lot better off.
Any help is greatly appreciated.
Marc, (Glad to see you spell it correctly....)
Try selecting the objects and then using the Add to Workspace command, there should be an icon for it in the icon bar. You will need to uncheck the "Reuse Content From Target Workspace" option.
That should download a fresh copy of the objects to the workspace, replacing the modified ones.
Confusing as he!! I know, not sure who that made sense to...
Thanks for the reply, it appears that it just took a while for my changes to take affect. This morning it was no longer an option to reuse content during an update
Unfortunately my changes did not *entirely* take affect - if i hit update in a Firefox based windchill session, there is no option to reuse content and it downloads the latest from the server commonspace. This is what I want. However, if I hit update in the embedded browser within Creo, the default action is to still reuse content - I have to manually tell it to download most recent from the server. This is NOT what I want.
While I understand the difference and implications and I can probably remember to use the correct settings, I cant expect that all the other CAD Authors using the software will. Does anyone know why the embedded Creo browser would act any differently than a Firefox session of Windchill?
Also, I did place the suggested parameter into my config file dm_overwrite_contents_on_update set as YES and that made it so that when I update an assembly from within Creo (not a browser) it does download latest from the commonspace. Thanks for that Martin.
Any suggestions to fix this would be much appreciated, I know there's a lot of issues with Windchill but I'd like to focus on fixing the issues.
Why would someone decide to redefine the meaning of "update" to something else? Update doesn't mean update anymore. What were they thinking? Someday I'm going to meet one of these programmers and maybe we'll be able to come to an understanding. I have never seen a program so unintuitive.
Not just confusion, sometimes it actually works, and sometimes it does not. THAT is far more concerning. I don't have any trust in this software....ZERO.
We are now almost done with a project here that used a top-down assembly (skeleton), and have had TONS of lost work and problems because Windburn refuses to actually update the parts referencing the assembly, or worse, updating the skeleton that drives everything. This is totally absurd. We've found here that sometimes it's more robust to do an update, not in windburn, but while in the part or assembly. Of course, sometimes even THIS does not work, and worse, doesn't show in in the workspace that it's out of date, leading to HUGE problems. I've found that the ONLY reliable way to make sure you have the latest files is to DELETE ALL the files in question, then re-add them to the Workspace again, unchecking the re-use box.
This is truly pathetic. I should send PTC a bill for all the man-hours we've wasted on this garbage.
I've said it before and I'll say it again: This is, by far, the WORST software I've ever used, anywhere, in almost 30 years of using software. That it's supposed to play such an important role makes it all the more frustrating.
If you are seeing inconsistent behavior with the Update and Add to Workspace functionality or with the config.pro options used in conjunction with Windchill then that should be investigated by PTC. Were cases ever opened for this?
In general, Update should update out-of-date objects (i.e. there is a newer version on the server because someone else checked it in while the user had it in their workspace). Add to Workspace should let you bring in other non-out-of-date files, where you can either reuse the content already in the workspace or overwrite it. Workspace synchronize will update metadata changes (lifecycles, etc.) from the server.
If that's not happening then it would be good to investigate the use cases you are seeing to figure out why.
Windchill works great if you are a content consumer. A content consumer can freely delete workspaces as there is nothing they need in them and create new ones to load the currently desired information.
In a collaborative content creation environment, Windchill is frequently a hassle.
While I understand there needs to be a lot of redesign to do so, content creators need a system that pushes changes, not waiting for participants to pull them. That is, if I'm working on a complicated assembly and someone else on the team checks in a new version of a part that's in that assembly, then Windchill should push that update automatically to all the Workspaces that item is in and the active Workspace should flag Creo that a new version of the part should be loaded into session.
This means part files and meta-data.
Flagging is required for those working on As-Stored data, but that could also be handled with a "Don't Update" flag on the Workspace.
Instead, in a team environment, Windchill withholds new information unless specifically requested, leaving a pie-in-the-face / rug pulling situation. This is especially true for family table management where Windchill won't automatically gather (at least through 9.x) all the members of a table for Update that are in the Workspace. Instead it's like HAL 9000, "I'm sorry Dave, I can't do that," followed by a lengthy separate search for all the individual family table members because Windchill isn't programmed to update the instances when the generic alone is chosen.
Another place for confusion is where an unwanted change is made.
The choices are Update and Add. In Intralink, where a lot of people started, Update would overwrite the Workspace version with the Commonspace version, discarding unwanted changes. This is not the same behaviour in Windchill, causing no end of problems for people during their learning transition period.
There should be a clearly defined operation, like "Restore" that would take modified items and restore them with the Commonspace configuration. Software developers may love overloading operators, but humans don't do so well and benefit from clear differences in descriptors and vocabulary that doesn't change meaning.
I agree David. I've made the "HAL 9000" reference several times in the past as well.
Oh, and here's another one: Often, we have new users that roll the rev beyond (sometimes FAR bayond) what it should be on accident. If the part should be at rev B.12, but has been advanced to C.1, as a medium-level admin, I should be able to roll that C.1 rev back to B.13. NOT being able to is a crock. I understand that not even the top admin can do it. That is a huge limitation.
As I mentioned Lori, sometimes it does, sometimes it SAYS it does, but doesn't.....with no warning but instead a line that says "All objects up to date"....which is a lie. Thankfully for our major project, I KNEW what geometry changed, and when I didn't see it appear on someone's system, I deleted the file and re-added it to their Workspace. This is inexcusable and puts us in an untenable position. Since I control the skeleton I know what changes have been made, my users don't, so when update does NOT work (more often than not) there's the chance for big trouble.
I've filled out tickets, and the result is......nothing. In all the tickets I've submitted, there has been no resolution that I haven't found myself, or simply worked around, or just dealt with. Honestly, I'd recommend my company dump maintenance completely and just buy new seats every couple years....it'd be cheaper and less hassle.
My main problem with Windburn? The fact that Intralink, which we HAD, was so much better, but corporate greed led them to strong-arm people by making new files incompatible with Intralink, so we HAD to switch. I resent that attitude and those business practices.
I've been a loyal power user for over 18 years now, but things like this seriously make me want to switch to, and RECOMMEND to my company, a switch to Solidworks.
As I mentioned earlier, if you're seeing inconsistent behavior it should be investigated by PTC via a techincal support case, and the functionality regarding update should be the same across the board (i.e. only update objects marked as out-of-date). I tried looking up your past cases, but didn't see any in the list that looked to be related to update functionality. Do you recall case number(s) for this? Were reasons provided for the behavior you were seeing?
Lori is correct. If there are specific scenarios or data sets that you are finding where the Update action is not responding as expected cases need to be filed with technical support so that these may be evaluated and addressed by PTC R&D.
I've been on a very rush project for some time now. While I've tried to help PTC in the past using my own free time, it didn't seem to help and it did nothing for me. "IF" I have some spare time on this project and run into the issue again, maybe I can file a case number. To date, I've had almost zero luck with any of that over the years, so you must excuse me for being somewhat reluctant to do beta testing for PTC.
I'll be blunt, I hate the product, and so does almost everyone else I've talked to, at 3 different companies and on here. All the more disappointing since I (and many others) really liked Intralink. Tired of having to make excuses for it to the ex-SW Engineers we hire who are constantly complaining about it....for good reason.
I so feel your pain. I am a long time Pro/E/Creo user since the early 90s, and now I administer a fairly large group of engineers using Creo 2.0, and Windchill 10.1 M020. It has been rough since Windchill came along. PTC offers system and business courses which cover nothing about how to truly manage and troubleshoot the system. I won't even get started on tech calls right now....I am not a JAVA programmer neither am I a DBA both of which seem to be a prerequisite for administering this system. There are some guys in the community who seems to know quite a bit about it, and not sure where they got there training. Just wanted to say that I empathize with you on this issue, and I wish more people would make more noise about it of just sitting back and taking it. My company division, not to mention the whole corporation as a whole pays TONS of money in maintenance, but there is no benefit. I have been trying to work through an upgrade for over 3 months now....still have not succeeded.
@Bryant we have spent into the hundreds of thousands of dollars (not including the maintenance and software) and more than 4 years in getting our Windchill system to work the way we wanted. At first we tried just having CAD admins do it with help from IT, but as you are finding, it is not possible. We quickly found that there is no one at PTC who understands how it works holistically. They can offer support on specific details, but we found we didn't even know what questions to ask.
Everything requires customization from simply getting correct mass data out of Creo (yes, at this tme it still doesn't do this out of the box) to exporting useable bills of materials. You essentially get a framework and options that do things that companies might need, in a terrible interface, and you have to customize it to do something useful for your company.
We tried hiring consultants to configure it, but that only got us part way. Finally, we ended up hiring a seasoned Windchill administrator, who previously worked at a well known Windchill integration company. That's when all of the pieces finally fell into place.
Now we have a fairly robust production system and a stage system to try out upgrades.
The initial quote we got from PTC to upgrade from Intralink to Windchill was $50K; in reality it is an order of magnitude higher and you'll need to hire at least 1 person dedicated to getting it configured and keeping it running and nothing else. You'll also need other people who can support java, system building, network monitoring, etc. And you need the entire company to be dedicated to using it and working out the bugs. It also requires that your processes are well defined and you have a clear plan on how you want to use it.
I would say that customers who want to undertake a move to Windchill should expect to spend half a million dollars, minimum, for a small enterprise.
If you need help, PTC will only lead you to frustration. Instead, contact the following companies who helped us immensely:
Thanks for the links Domingo!
I concur 100%. What a nightmare. I want my Intralink back! I'd switch to a 3rd party vaulting system in a heartbeat. PTC, are you listening?
We are listening. Martin explained the Windchill update behavior above quite clearly. We hear your pain and understand that change is difficult. But.... PTC supports Windchill for CAD DM, and while we can't make everyone happy, we do the best that we can.
As this is getting some attention, is there any constructive advice that could be given to my issues I posted in reply above (starting 7 posts from the top, http://communities.ptc.com/message/269138#269138). We're a smaller company starting out with pdm essentials and while we've certainly had our share of pain with windchill, I'd really like to focus on improving our implementation.
It's difficult to address your issue from your description. If you read again Martin's explanation, Update is to be used when there is a later iteration on the server. Is that always your case? Or is it just that they want to undo the changes that they made in the workspace. In that case Update cannot take a later iteration from the server. As others suggested in this thread, you can use Add to Workspace to get the latest as long as you uncheck the box as Marc Bower suggested.
I wasn't sure from the thread if you did use Add to Worspace action becuase you keep mentioning update in the embedded browser.
Thanks for the response. My issue is simple really, Windchill update is acting different in a stand alone browser vs the embedded browser. Did you read my posts leading up to the last? If WC would do the same thing in each browser I'd be less confused.
I've set the "reuse modified workspace content" option to "no" and in a browser based session of WC it acts as you would expect, it does not allow you to reuse modified content on update - the only option is to download. This is what I want. However, in the embedded Creo browser when I do the same operation the default is to reuse modified content. This is not what I want. Is there any settings that cause the embedded browser to function differently than a standalone browser?
I wonder if part of the confusion is due to the workspace cache. Because the cache is on the local client's HD, the embedded browser is the only way to see into it. I would recommend using the embedded browser whenever making changes to the workspace.
The standalone browser can only see the server side of your workspace and not the local side. This has caused issues for people here in the past.