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

Unverified Family Table Instances in Pro/E WF2 & Pro/I 3.4

Highlighted
Newbie

Unverified Family Table Instances in Pro/E WF2 & Pro/I 3.4

I'm sure there are many that have encountered this problem, and I'm hoping someone has a slick solution.

We use family tables extensively and have a fairly large Pro/INTRALINK 3.4 database (120 GB). We recently completed our migration to Pro/E Wildfire 2.0 from 2001. Now, any time a family table instance is loaded, either individually or as part of an assembly, the user gets a message that the family table is unverified and that the user must verify that family table prior to saving. It appears that this is the case for any family table item last saved in Pro/E 2001. Once it is verified and saved in WF2 and checked backed in to Commonspace, the problem does not reoccur.

I'm sure many of you can appreciate the huge task that presents itself as a result of this: all family tables now need to be checked out, loaded, verified, saved and checked back in to the database. This is literally tens of thousands of items that would require hundreds of man-hours to complete manually. PTC Tech Support says they have no solution to this, other than spending the many hours to do it manually. I'm hoping that somebody has come up with an automated way to do this (using scripts, Pro/I Toolkit, etc.) Companies like John Deere, Caterpillar, Toyota, etc. must have run into this during their migrations and must have come up with a solution. If anyone is willing to share, or has any ideas on how best to handle this, I'd appreciate hearing from you.

Thanks.

1 REPLY 1
Highlighted

Re: Unverified Family Table Instances in Pro/E WF2 & Pro/I 3.4

> Perry Edmundson wrote:
>
> We use family tables extensively and have a fairly large
> Pro/INTRALINK 3.4 database (120 GB). We recently completed our
> migration to Pro/E Wildfire 2.0 from 2001. Now, any time a family
> table instance is loaded, either individually or as part of an
> assembly, the user gets a message that the family table is
> unverified and that the user must verify that family table prior
> to saving. It appears that this is the case for any family table
> item last saved in Pro/E 2001. Once it is verified and saved in
> WF2 and checked backed in to Commonspace, the problem does not
> reoccur.
>
> I'm sure many of you can appreciate the huge task that presents
> itself as a result of this: all family tables now need to be
> checked out, loaded, verified, saved and checked back in to the
> database. This is literally tens of thousands of items that would
> require hundreds of man-hours to complete manually. PTC Tech
> Support says they have no solution to this, other than spending
> the many hours to do it manually. I'm hoping that somebody has
> come up with an automated way to do this (using scripts, Pro/I
> Toolkit, etc.) Companies like John Deere, Caterpillar, Toyota,
> etc. must have run into this during their migrations and must
> have come up with a solution. If anyone is willing to share, or
> has any ideas on how best to handle this, I'd appreciate hearing
> from you.

We experienced some of those issue after upgrading to WF2 from 2001
while using Intralink 3.3 for both versions. It was a very annoying
problem as it usually interrupted users from saving their work. There
are workarounds, but it is still very annoying.

You not only have to fix the problem as you said, but identification
is also a major factor. We found that only a small subset had this
problem. Unfortunately, some of them were very commonly used screws,
which made things more urgent. If you can properly identify where the
problems are, you may save yourself a lot of time.


I used Intralink Scripting to find the problem family tables. This
was a little time consuming, but this located the problems quickly
enough. SQL can identify the problems much more quickly (minutes vs
hours).

Here is an SQL query that should do this:

set linesize 120
column genname format a35
column instname format a35
column instrevver format a10

select
loname as genname,
VERIFIEDSTATUS,
ipi.piname as instname,
ipiv.pivrev||'.'||ipiv.pivver as instrevver
from
pdm.PDM_LO lo,
pdm.PDM_LOV lov,
pdm.PDM_LOVCONTENTS lovc,
pdm.pdm_productitemversion ipiv,
pdm.pdm_branch ibr,
pdm.pdm_productitem ipi
where
lo.loid=lov.loid
and lov.lovid=lovc.lovid
and lovc.pivid=ipiv.pivid
and ipiv.brid=ibr.brid
and ibr.piid=ipi.piid
and VERIFIEDSTATUS is null
and LONAME!=ipi.piname
and (ipiv.PIVREV = pdm.rvmax(ipiv.BRID))
and (ipiv.PIVVER = pdm.pdmsp_oqlfunc.pivlastver(ipiv.BRID,ipiv.PIVREV))
order by
genname,instrevver,instname
;

Notes:
The last two lines in the 'where' clause will slow things down
greatly, but they limit the results to the latest version of the
instances. You can leave them off to speed things up for very
large Commonspaces (more than 1 million PIVs), but the results
may not be the latest Rev/Ver, which could have already been fixed.

You'll get some strange results if you have family table orphans
(instances not associated to the latest version of the generic),
but the query is generally correct.


The advantage of using Intralink Scripting was that we could easily
get a where used report on each of the problem instances at the same
time. This allowed us to prioritize the family tables urgently needing
attention, versus models that have never been used in any assembly.


Once you have a list of generics, you can use Olaf Corten's IlinkTrail
program to checkout, verify, and save each family table. I imagine if
you perform these steps in batches of 10-20 generics, you should be able
to take care of things in a reasonable amount of time.


Marc















Announcements