Continue to Site

Welcome to MCAD Central

Join our MCAD Central community forums, the largest resource for MCAD (Mechanical Computer-Aided Design) professionals, including files, forums, jobs, articles, calendar, and more.

How Not to use Intralink

jeff-gabby

New member
Hi All,


Here is an example of How Not to use Intralink. Count how many workspaces this person had. My question. Does anyone have any links or info on how wrong this is so I can use it to fix the problem.


View attachment 840
 
If I was working on 16 different and completely separate projects, I'd have that many also.


However, If the WSs share components, then having separate WSs can be a pain.When you change a part in one WS, you have to check it in and update in the other WSs just to keep up with yourself. (I guess exporting to WS would also work). Asa terrible analogy, "it's like building walls between yourself and yourself". (although I guess that's actually a terrible simile...)



Edited by: Brian_Adkins
 
Hi Brian


Just to clarify, it is not me that has this many workspaces. This person has had these jobs over the past year. This person works very hard to defeat the Intralink system, so they will not check in files. The big concern I have is that the desk top is not backed up. I was not aware that this person had this many files and workspaces not checked in. How do I get this person to do so with creating a fist fight?


Tofflemire
 
>>How do I get this person to do so with creating a fist fight?


Sneak up from behind?


The not-checking in thing can be scary, unless you're the person who just doesn't care... I've had a few here who didn't care right up to the point where they lost work (several weeks worth) due to not checking in (WSs got wasted). Only then do they actually seem to 'get it'.


By leaving your company's data in a location that is not 'safe' [backed-up], this person is putting his/her paycheck at risk in my opinion. I'd at least keep a copy of an email notifying that person that if his/her local machine dies (i.e. hard-drive crash) that no local data will be recoverable and that he/she will have to explain that to the boss.


As administrators, I think we often feel personally responsible for other users to a point where we forget that we can't make people do their jobs. In this case, if the persons job is to do the work and ensure that it can't be 'undone' then it's your responsibility to make sure they know what needs to be done and then cross your fingers.


Alternate plan, you could copy their .proi to a backed-up locate nightly. I've done this a few times before major upgrades using a simple copy script that can run late and night after users log out.
 
Here's a funny idea... I've seen this done with factory safety reports, etc...


Write an Intralink script that spits out the number of new/modified objects in all the workspaces whenever the users logs off. This will be the work-in-progress that has not been checked in. Then rank everybody to see who really has the most "objects at risk" in the office...


... hey, that's actually not a bad idea.... I might try that!


-Brian
Edited by: Brian_Adkins
 
I like Brians Idea, make a worst offenders list.
I am sick of telling users the same, check in does not get backed up, etc. Problem you have with backing up objects is if the object was ever renamed and the .proi does not restore good which never seems to work here. Whenever we tried to restore a .proi the thing is corrupt.
Here is my 2 bit story: Here there was 1 engineer working on a new project, which he checked in 1 time at the end. He was working on it for over a year, and they went to get a patent. Long story short they were trying to prove the time it was created because another company was doing so as well and they said they were first. I ended up in legals office explaining the dates on the files and basically told them that the audit trail shows only the date of the start file and the last save, and the manager was telling me that he knows that it was saved more than that and why did it not show up in Intralink, my answer was simple, it was never checked in. Needless to say the lawyers asked why he did not check it in and was it difficult and my answer was laziness or lack of knowledge. Because of this they did not pursue the patent. You would think that this person would have learned from it and still to this day he still does not check in on a regular basis.
 
If you have administrative rights and persistent lazy users, write a
batch file script to go in to their machines through the back door and
copy their work files to a secondary backup area. Schedule it to run
when you know their machine will be running and connected to the
network.



Get into the habit of backing up files on users machines (daily is preferable) as well as those checked in.



Don't allow political correctness to potential destroy your project.





DB
 
>>through the back door and copy their work files to a secondary backup area


If the workspace gets correupted or goes missing, the 'back-door' copies have limited usefulness. Grabbing the entire .proi folder intact for every backup would be better. We do this occasionally during Intralink upgrades.


Also, in my case,we're talking about several gigabytes per user and about 50 users. That's a couple hundred gigbytes of data, and possibly only 5-10% of it may actually be modified data that is not already backup in the commonspace. However, this would probably be a good idea in some places.


We run into the same problem with users storing spreadsheets, etc. on local hard drives. They all have 'private' network storage locations, but some choose to ignore it despite multiple notices from our IT departments. The result of this is that our IT group will now begin installing backup software on local machines which will drag down our computer performance even more. However, even then, the local users will be in charge of telling the backup program what to back up and making sure that they put their local files in those spots.


...no such thing as making something trulyidiot-proof in my opinion.
Edited by: Brian_Adkins
 
I've also seen issues here when users keep a large number of "active" workspaces, since they don't want to check in the objects (they may be concept parts, or still waiting for real numbers)... I usually just make it clear that the data is not backed up, and they run the risk of losing the data... This has happened once or twice, due to hard disk failures, etc, so we have some evidence to use.


Brian - interesting one about doing a script... how would you set that up? - ie: how do you export new/mod. items at logoff? I started thinking UI scripts, but that may be a bit intrusive? - stalling the user when they just want to logoff.


In the past, before intralink upgrades, I had a script that collated lists of user workspaces & allowed us to see the worst offenders ... and pay them a visit.


Ed
 
proed: you're right... it would probably UI scripting in my case and would probably aminute to run. I would probably only enable this script once a month or so.


to get a list of the user's workspaces:
c:\> dir /b /ad <path-to-proi-folder> |findstr /v /c:"."


Next, I'd write a UI script that
- logs into Pro/I
- opens workspace <X>
- sets display to show only name
- filters display where workspacestatus is not empty (new/modified)
- prints the resulting workspace to a text file named <workspace>_<timestamp>.txt
- exits Intralink


Then a batch file to use the list of workspaces created above to feed the UI script via an environment variable. So if a user had three workspaces, the batch file would kick off the UI script three times for that user (in no-graphics Intralink mode).


Then it's justa process for the batch file to open each resulting text file and count the number of lines. For a user that had five workspace, I'd image this whole process taking less than a minute.


I have similar scripts set up to spit out a text file containing a list of workspace models with parameters undesignated that should be designated. They show up as "--" in the column for that attribute. This list of files is thenfed to a Pro/E trail file which opens each model, designates the parameters, and saves the model.






Edited by: Brian_Adkins
 
Brian


Once again I learn something new from you... in this case the FINDSTR command... pretty useful what you can do with it!


That process sounds like it would work (but maybe a lot of effort to get there!) - good plan to filter display for non-empty values.


Ed


ps - how would you recompile the UI scripts to include correct workspace names..? I was sure there was a command-line code, like -r for record, -p for play, -? for recompile?
Edited by: proed
 
Ed,


I used to use the "Recompile-on-the-Fly" method, but it was kind of sketchy. However, a co-worker knowledgeable in JAVA showed me how to do the following:


By tweaking the java source after recording a script, you can set it up so that it can reference XP environment variables


Let's say yourscript consisted of these steps:


1) Log into Intralink
2) Open specific workspace
3) Customize the display
4) Print contents to a text file
5) Exit Intralink


You can alter your script such that step #2 is based on an environment variable and is no longer hard-coded into the script. Then your batch file could look something like this:


:: First run the script on Workspace "nuts"
set WSNAME=nuts
call intralink.bat -- -p script.class
::
:: Next run the script on Workspace "bolts"
set WSNAME=bolts
call intralink.bat -- -p script.class



-Brian




Edited by: Brian_Adkins
 

Sponsor

Articles From 3DCAD World

Back
Top