Save Vs. Save and Upload

[jbennett]

Does anyone have an opinion on this or have a pros vs cons of each?

[RonGrabau]

Save only saves to your local cache located on your local computer. If you local cache/computer gets any errors, you can pretty much kiss your modified or new objects good bye.

If you upload, then the files are on the server side of your workspace. If your computer dies, all you need to do is get on another computer and all of your work will still be there.

If you don't back up your computer or worry about local cache corruption (it happens) then the save and upload is your best bet. If you like living life on the edge and don't worry if you are going to lose work and like redoing what you just did because it always goes faster the second time, then by all means just keep saving to your local drive.

Uploaded files and Commonspace are all on your server. Normally your server is going to be more stable than your local drive. The only issue I know if is that the upload will take longer. If you are on a WAN, then you will have to wait for each save/upload to complete and it increases network noise. If you have a poor network and your server is across the country or overseas, this could be a problem.

Ronald B. Grabau
HP PDE-IT
Roseville, CA
916-785-3298
-<">mailto:->

[DonSenchuk]

Upload pushes a copy of the saved file to the server-side workspace in which is resides. This means the saved file can be accessed from another workstation if that user needs to do so. (For instance, if the modifications are not going to be checked in.) This also means on the rare occasions a workstation is changed or suffers a mysterious crash, every save will be retained even without a check in.

I keep our config set to automatically upload on every save. While some of my users even pay attention to when an upload fails and try to resolve the issue right away, most just ignore it because there are so rarely problems associated with it.

I've made sure the configuration is set this way at two previous positions as well.

The downside is (supposedly) network traffic. I've never seen any slow-down from the user's standpoint and no IT department has ever complained about the network traffic from this. (Though to be fair, they may not be able to tell between the automatic uploaded files and a legitimate upload/checkin without extra work.)

If I were to make a recommendation, I'd say to set your config.sup to dm_upload_automatic YES and let the users just pick Save.

[mdebower]

I agree with Don. We have it set this way, and our server is half way across the country. I have had large customers who visit us, tell me that the system response is faster than their in house server.

-marc
CAD / PLM Systems Manager

[AndyHermanson]

Do you know if your users have Gigabit connections to their computers or 100 megbit connections?

Andy Hermanson
Engineering Design Applications

tel 605.275.1040 x51114 mobile 605.310.8168
website www.daktronics.com

[mdebower]

Andy,

We do have Gigabit internally, but once we go outside of the firewall it drops to ISP levels. Sometimes I think my cable connection at home is faster than at work...

Note, I am not saying that it isn't slower than a LAN, but rather that it is acceptable and only noticable in extreme conditions. (Large files, lots of them, etc...)

-marc

[davehaigh]

I'll agree with others that you really should use dm_upload_automatic YES

But as for loosing files when your cache gets corrupted, that's not entirely true.

The files are still there in the cache and are still good files. You just need to recover them.

You need this program from the PTCUser site:
[cid:image001.png@01CDAD19.101B61B0]


David Haigh

[mganzer]

Simplest rule of thumb I've given to users is upload when working with reasonably sized files (whatever that means). When working with large files save during the day and upload before you go home.

[MikeFoster]

One more (minor) consideration: Each upload adds the file to the vault. If it never gets checked in the file in the vault becomes unreferenced. When upload is automatic vaults need to be cleared of unreferenced objects more often.

Mike Foster
ATK

[#10]

I used to be a Windchill consultant. Rarely would I recommend that
"dm_upload_automatic" be set to yes.



IMO, it is a crutch to educating users and taking away their ability to
decide for themselves what needs to be done when. Instead, the users
need to have clearly explained what the workspace and cache architecture
of Windchill is and how "Save" and "Save and Upload" are different.



Understanding the impact of client and server-side workspaces is very
important, not only for this case, but also in terms of the embedded
browser vs. a stand-alone browser and when a user uses more than one
computer to access Windchill.



Setting to Yes consumes bandwidth, disk space, and table size
(temporarily). Save regularly, upload once or twice a day (unless you
have 'special' needs).



~Dan







Dan Harlan
Mechanical Engineer / CAD Administrator
480.940.0036 x178 Office
480.940.0039 Facsimile



481 N. Dean Avenue
Chandler, AZ 85226
dharlan@aitint.com
www.aitint.com

[STEVEG]

Dan,

I respectfully disagree. The reality of it where I work is that many of our user's (mostly outside of engineering) do not care to worry about that. They EXPECT the system makes sure they are protected. Case in point: we updated our drawing formats earlier this year and let everyone know they must use it. There were a few people that forgot when they processed an ECN. When we told them about it one person wrote another ECN just to replace the format citing "the system did not notify to update the drawing format". And they processed a couple more ECN's with that description.

We have had situations where the hard drive has gone down and had to be replaced. Not a good thing if you don't upload.

In the training that we do for PDMLink we explain the uploading process and that it is set to do so automatically. Not one person, ever, has said they want it turned off so they can do that themselves.

In my opinion automatic upload is a good way to be proactive. Not reactive as you suggest. And in the case of the hard drive going down it doesn't even seem to be reactive. It's noactive. I would trade losing work with the safety of automatic upload and the minimal use of bandwidth, disk space and table size any day. Unless, of course, it takes an hour to upload.

I would like to know if anyone agrees or disagrees and their reasons. I might be missing something here but I am not above switching my view.

Steve G

[DonSenchuk]

With all due respect to Dan's position, there are a couple things I'd like to point out.

First, the customers I've had to deal with generally don't give a crap about being educated in this regard. And by customers I mean the coworkers I have to support. The engineers and designers want to get on with designing. The drafters just want to get on with model/drawing creation and clean-up. The checkers just want to get on with checking. The people assigned various roles in workflows want to get on with their job.

I've had a few over the years ask what upload does out of real curiosity. I've yet to see one get through the explanation without losing interest. As long as the software works from their vantage point they don't care about the rest.

Second, if an organizations systems are so close to the edge that the automatic upload causes a problem due to bandwidth, disk space or table space, there are more serious and immediate problems to deal with than this.

[Lohbauer]

Dan,

You make a solid point at a philosophical level. An educated user will get more from the tool the better they understand its functionality. However when we migrated from IntraLink 3.4 to PDMLink 9.1 last year it was a shocking change for some users. During the training process the notion of Client and Server side workspaces was not easily grasped due to the IntraLink paradigm they had been accustomed to. It is an ongoing training challenge still. So I set the ‘dm_upload_automatic’ to yes as a security measure. This has proven to be a good choice in many cases when users for whatever reason find their local caches corrupted.

In time once our users have fully adopted and I’m comfortable they ‘get it’ perhaps the setting will be changed. While it does consume bandwidth and I do find myself doing a little more vault maintenance, at this point in our adoption it makes too much sense not to.

Bob Lohbauer

[DamianCastillo]

I am new to all this and currently tweaking our Windchill 10.1 configuration. I have no data migrated yet.

We did choose to automatically upload with each save because our assemblies are small and we have a Fiber backbone that is very fast.

You simply need to consider your infrastructure and make the best call for your situation. We have the speed and our files are not large so we decided the server side workspace gives us peace of mind that our work will not be lost due to corruption or a users computer crashing.

I am still learning, so I really enjoy all the feedback from veterans.

"Too many people walk around like Clark Kent, because they don't realize they can Fly like Superman"

[BenLoosli]

This slide from our Windchill training helps show what each option does and how the file is stored.

[cid:image002.png@01CDADE4.2E7E72C0]

This slide illustrates how data moves through the system from a Pro/E session to a Windchill shared folder
The solid lines show the main purpose of the different commands (e.g. checkin moves data from a users private folder to a shares folder)
Dotted lines show where the Wildfire integration is optimized to allow multiple operations to happen with one end user action (For example, if the user checks the "Open in Pro/E" checkbox on checkout, objects will be checked out to the user's private folder and files will be downloaded and opened in the user's Pro/E session)
There are four locations that file data can exist in, and the Wildfire integration is responsible for marshalling that data between these locations as a result of user actions

Check Out

During a check out operation, data is transferred from the Windchill database to the workspace. Optionally, if you choose to open the object, the data is then transferred from the workspace to Pro/ENGINEER.

Check In

During a check in operation, data is transferred from the workspace to the Windchill PDM database. If you check in an object directly from Pro/ENGINEER, the data is transferred from Pro/ENGINEER to the workspace and then to the Windchill PDM database.

Upload

During an upload operation, data is transferred from the client-side workspace to the server-side workspace.

Download or Update

A download or update operation transfers data from the PDM database to the workspace. You perform an update, to update existing and potentially out-of-date object information in the workspace from the PDM database.
Process for updating objects in WS:
Use "Update" if object current status is "Checked-In"
User "Download" if object current status is "Checked-Out"

[BenLoosli]

I will also disagree with Dan and join Steve, Don and Robert in the use of dm_upload_automatic set to yes.
The users here have been taught to look at the messages when they save a file to see if the upload has been completed successfully. There are many instances where the save completes, but the upload doesn't. This allows them to investigate the reason for the failed upload and correct it before the issue gets worse. In some cases an upload from Pro/e save may fail, but an upload from the client-side workspace can go through.

We are on a fiber network to the workstations and contained mostly in one building. Bandwidth is not an issue. Disk space is cheap enough these days that that is a non-issue. The only 'extra' work is to remove unreferenced files from the vaults more than once a year.

Thank you,

Ben H. Loosli
USEC, INC.

[Lohbauer]

Ben,

FYI, I have the unreferenced files scheduled to be removed weekly.

Bob Lohbauer

[jbennett]

Thanks for the responses. I always push the full check-in as the safest method, but I also try to expain the differences between the save vs. upload options (which most of the users get a glazed look on their faces because they don't really care how it works, they just want it to work all the time).

Personally I always played it safe and performed the save and upload instead of the save only when I was part of product design. The other issue that I face with the CAD users I support is thatI have only been the CAD admin for about 5 months. I used to work under alot of the people I know train and support so the advice on best practices that I offer are often looked over or not taken seriously.

John Bennett

CAD Business Admin

Lifetime Products

www.lifetime.com

[LEONIDGUREVICH]

I want to check next spelling - "dm_upload_automatic YES", is it true?

I have in my config.pro next row: "dm_upload_objects automatic"

[cid:image002.jpg@01CDAF5C.185666A0]

[DonSenchuk]

Automatic is correct. I must have remembered an older version of that config being YES.

(Or maybe even a different config, knowing how my memory works!)

In Reply to LEONID GUREVICH:

I want to check next spelling - "dm_upload_automatic YES", is it true?

I have in my config.pro next row: "dm_upload_objects automatic"

[jhowell2010]

A user at our site saved & upladed his files. He then cleared his workspace & deleted his cache without thinking to check-in the objects. Doesn't deleting the cache only affect the local workspace? How do you recover the data from the server-side workspace when nothing is showing up?

[TomU]

You are never viewing "just" the local workspace. When using the embedded browser connected to a Pro/e session, you can see the items in your workspace as well as items in the local cache that haven't been uploaded yet. If you delete something, it is removed from the "workspace". Period. The local workspace will always be a reflection of the server side workspace plus any new, not uploaded items in the local cache.

As far as recovering the data, everything uploaded to the server will be in your file vault. Nothing is going to have friendly names though, so locating the data will prove a challenge. There is a utility on the PTC user site that can search through files and attempt to figure out what the actually Pro/e part name is. You might want to download that and try it on a copy of your most recent vault data.

Tom U.