Another Intralink question

Sorry for the duplicate question, when I sent this one this site gave me a message of server error. Didn't think it went through.

Frank,

It is hard to understand your question but it seems that you are either trying to fool the system somehow or you have done it inadvertantely. What you should do is avoid going in and out of your workspace in the future. The only time I perform a similar process is when I get files from outside my business and need to import them into Pro/Intralink. (I have never even tried a "quick check in" and don't plan to in the near future either.) In those cases, I start Pro/Engineer in the desired workspace (usually a special one created just for this task). Then, I open the subject file. Finally, I save the file to the workspace.

Naturally, you would think that that is the end of it. Well, you would be wrong. At this point, you should (but probably don't have to) close Pro/Engineer and get to work on the workspace. The first thing you have to do is find out if you managed to duplicate file names that already exist or use file names that are illegal. Then, you have to fill in all the necessary parameters for your particular Pro/Intralink set-up. In my case, I must select a folder for the files or nothing works. (I set up our system this way to avoid problems with people not selecting a folder). Make all the necessary changes and entries before attempting to check in the files.

During this process you might find any number of errors. I mentioned file name conflicts. This is quite common and one reason we use Pro/Intralink in the first place. Of course the other big reason is version / revision control. And, a nearly invisible thing it is good for is keeping all the drawing sheet formats from being corrupted. Each time you attempt to save a drawing Pro/Engineer will attempt to save the part / assembly, the format and the drawing. The special format files are usually set-up in a commonspace folder with special protections. That's at least three seperate files any of which can create a conflict which must be repaired before check-in can succeed.

If none of these is the problem than it is quite simply an incorrect installation of Pro/Intralink in the first place. Your Pro/Intralink administrator simply has to reconfigure it (run "ptcsetup" in the Pro/Intralink client directory ... no CD or additional setup files are necessary). Although I have done this dozens of times I can just barely remember how to do this. It will be quite obvious because there is a point in the set-up where you fill in where the Pro/Engineer startup batch files are. All of your workspaces can inadvertantly be corrupted during this process so be carefull.

Now that I think about your problem a little more this last is probably your issue. I have had to delete and re-create a couple of bad batch files in the past to make the Pro/Intralink installation work. This is really easy for the administrator to take care of but unless you are very familiar with what you are doing I don't recomend you try this without assistance.

Frank

My company have been working with various Intralink/ProE versions (in combination) over the last years and i have never seen the behaviour. I think a fresh install of Pro/E and the Ilink client will solve the problem, if not check on a different computer if you get the same problem.

Hugo

Frank, like the others I'm a little bit confused, but I'll take quick stab at what you are looking to do here

You are working in Blo-e via a workspace in IntraLuggage. You need t

open a part/assembly/drawing that is not in the workspace, so yo navigate via "File Open" to the file and open it

A couple of quick ?'s

1.) What build of Blo-e & IntraLuggage are you using

2.) Are you trying to save the information that is not in th workspace already

3.) What happens when everthing goes to hell, be more specific

Glenn |B

The first thing I don't understand is this atypical behavior: you open Pro/e in a workspace then open a file ignoring the workspace. The typical way to do this is to use 'File>Import/Export' to get files in and out of workspace, to communicate with the world outside of Intralink/Oracle. The advantage, besides giving your data tracking software a heads up as to what you are doing and letting it do its bookkeeping, is that you get to assign Intralink parameters right from the start: revision level is a good thing for Intralink to know and the imperative Folders parameter. You also give Intralink a chance to examine the file and tell you things about it, like whether it already exists in Commonspace, what it's CS status is and what it's WS and Compare statuses are, whether it's released, pending or locked. When you open a file as you did, without the intervention of Intralink, you risk all kinds of trouble as well as risking subverting the good functioning of a $100k software package. And it really doesn't need any help at all in crapping out on you. Also, by way of aiding its correct functioning and not helping it crap out on you: never (and I'm sure no one needs to be told this but JIC) go into the .proi/workspace folder and mess with WS files with a system file management function, like renaming, moving, deleting, copying files with Windows Explorer. You make Oracle sick and unhappy if you do.

Again, anomalous behavior: Quick checkin? when you haven't seen this file in WS, haven't set any parameters, including and especially a folder!?! Well, lets say that Intralink knew about this file, knew its rev, release level, folder, etc.: this further assumes that the release level wasn't set to Pending or the file would have had to be manually set to WIP in WS; it further assumes that it also wasn't a released file which would have necessitated changing the revision, none of which can be done while in Pro/e, all of which requires that the file be available in WS (which it is not at this point). There you would F2-Modify the file to change revision or release level, but this would have to be done before checking the file in if there were any incompatibility between the file in Pro/e and tyhe file in CS. If there were no incompatibility and checkin were allowed, the file would have to already be in CS and with a compatible revision and release level, otherwise, checkin would have bombed.

Now, this 'File>Checkin>Automatic' (the socalled "quick" checkin) does two things: it saves the file to CS and it saves a new version to WS (hopefully). But, does it, actually in this case. The Pro/e-Intralink combo has three methods available for deciding where to save a file: the typical Pro/e "working directory", the builtin WF2 Browser to locate and open files and the Intralink WS. When one opens Pro/e in a WS, one would think that files would automatically be saved in this area, yet, when one opens a file outside of WS, I can't confirm, nor has Frank confirmed, that the file actually gets saved in WS. If Pro/e used the "working directory" method, it would probably save the file in the top level of the .proi folder. If Pro/e used the Browser method to decide where to save the file, it could save it in the directory from which the file was opened. The anomalous checkin behavior only confirms this uncertainty. If the file had been saved and the WS opened from Intralink, parameters set/confirmed there and from there, checked in, I'd say that the file's existence in WS and proper check in were a lot more certain. In Frank's narrative, it is not certain at all where the file went or what happened to it.

Could it be that a more conventional approach would avoid all this heartache and aberrant behavior: 1) open Intralink, pick the WS button, Open an existing WS or Create a New one; 2)populate the WS with files using CS Locate or Import; 3) when needed file is available in WS, check status, modify revision or release level, set folder, etc., as needed; 4) highlight file and do Ctrl-O or RMB 'Open'. This will launch Pro/e in the WS with the file in session; 5) modify the file in Pro/e and, if a single part file, do 'File>Check in>Automatic' or simply save the changes to WS, then, within the WS, select the file and do RMB 'Check in'. If this is an assembly and any component files are plussed that you did not deliberately modify, select and 'Update' them. Then check in the drawing/assembly. Never try to check in an assembly/drawing when dependent parts/components have been modified without confirming that the modifications are not unintended geometry changes and that they are being made to WIP parts at the same revision. If you work in this way, you should have no trouble "seeing" workspaces, nor in checking in files to CS. If you persist in trying to circumvent Intralink, you do nothing but make trouble for yourself.

David Janes

My whole point here is the fact that after I save a drawing in pro, (that is loaded with-in a workspace), I have to exit pro-e in order to get to the workspace, so I can check the drawing in. Why do I have to exit Pro-e? I should be able to minimize it then re-open the pro-e window so I can continue to work. But, NO..., I have to reload pro-e each time, after using the workspace. With more than 3,000 files to put into interlink, opening pro, closing pro, is getting old fast. Frank

I don't know. I use Pro/e and Intralink every day. I use 'File>Checkin>Auto' for drawings of parts because there are never any conflicts that have to be fixed as there often are with assembly drawings. For assembly drawings, I open the workspace where the drawing/assembly/parts were saved, select and Update anything that I know won't check in because it's Pending, Released or Locked so that these file do not enter the check in list. I select the remaining, plussed files and check them in. I don't exit or minimize Pro/e. I also don't exit Pro/e to change workspaces; I just use 'Tools>Server registry' to switch to another WS. Your problem may be that you have so many files tght the system/Intralink/Proe hangs, waiting for something in the WS to update. Could be a memory problem, i.e., not enough. One thing that can greatly speed up redisplaying the contents of WS is to simplify your table view, strip this down, give it the bare minimum of pieces of information to to update. Once you've done something to alter the contents of a WS, Intralink goes dutifully about verifying the values of every paramter, in every column, for every file in WS. So, create a minimalist view that shows the file names/dates, maybe version #, nothing more. The less information, the quicker it'll display. When you're sure it's all good, switch to the data intensive view. It could be other things, too, like your Intralink setup. But this is the main reason I can think of that a whole lot of files will bog down your system and make you exit Pro/e to 'unfreeze' and make visible your WS.

David Janes

Frank, your right you shouldn't have to get out of Pro to get to you workspace, something is wrong. Are you using WF or WF2

If you are using Wildfire, you can go right to your workspace fro

within Pro, have you tired this

I got this from the PTC Knowledge base, if you don't have access t

it, get it

Hope it helps, Glenn |B

Title When Opening Objects From #Object #Open In Workspace

"loadinpro.exe" Should Be Used From Pro/ENGINEER Installatio Directory Rather Than From Pro/INTRALINK R3.1 Installation Directory

Product Pro/INTRALINK Module Pro/E - Pro/I Interaction TAN I

113611 Created 11-MAR-02 Workstation All Windows Reported In Release 3.1 Reported I Datecode 2001360 SPR 933755 Resolved In Release 3.2 Resolved In Datecode 200144

Descriptio

---------------- When the object is opened from #Object #Open in Workspace "loadinpro.exe" should be used from Pro/ENGINEER installatio directory rather than from Pro/INTRALINK installation directory

Starting with Pro/INTRALINK R3.1, "loadinpro" should be used fro

Pro/ENGINEER installation directory since the Pro/INTRALINK comman script specifies as a following For Windows NT set PDM_LOADINPRO_PATH=%PROE_DIR%\%proe_mc%\obj\loadinpr

However, it is still used from Pro/INTRALINK installation directory

As a related issue, please refer to TAN 109891

Alternate Techniqu

---------------- Add an extention for "loadinpro" in the Pro/INTRALINK Client comman script as a follow

Thanks for the Help. WF, we have not loaded WF2. I will add the extension to the script ASAP. But on the other hand, is it valid to add that to the script in WF?