Report of all object versions and their dependents object versions

All,

I am working on defining a process to archive our Pro/INTRALINK 3.4/
m030 vaults in preparation
for future PDMLink migration efforts.

As part of our long term archival process, I want to avoid
dependencies on the currently deployed
Pro/INTRALINK application in case we need to retrieve the data 10-15
years from now when operating
systems and hardware will be very different.

I want to generate a list of all object versions in our Pro/INTRALINK
3.4/m030 environment and
for each object version, a list of their dependent object versions. I
realize the output will be a
really huge nasty file, but that's OK.

If you have a SQL query that can do this and wouldn't mind sharing, I
would sincerely appreciate it!

Tom Hogan

 

All,

I am working on defining a process to archive our Pro/INTRALINK 3.4/
m030 vaults in preparation
for future PDMLink migration efforts.

As part of our long term archival process, I want to avoid
dependencies on the currently deployed
Pro/INTRALINK application in case we need to retrieve the data 10-15
years from now when operating
systems and hardware will be very different.

I want to generate a list of all object versions in our Pro/INTRALINK
3.4/m030 environment and
for each object version, a list of their dependent object versions. I
realize the output will be a
really huge nasty file, but that's OK.

If you have a SQL query that can do this and wouldn't mind sharing, I
would sincerely appreciate it!

Tom Hogan

I guess I'm missing something pretty fundemental here. Your archiving process involves Intralink vaults and you want to make them technologically independent with "lists"? I thought the archive vaults, archiving process, the dependency on Oracle metadata were inherently Intralink dependent and Pro/e dependent. No guarantee that Pro/e will even be able to open the files in 10 to 15 years or that PTC will even exist. But, without Intralink, what good are Intralink vaults? So, I'm not sure what your aim is or what the point of these dependency lists might be. Sounds like you're just trying to do a BOM dump of Oracle metadata. But wouldn't an export of all Pro/e data, based on 'as stored' versions, to some basic, generic file structure be of more use? I guess I'm just not understanding what these lists are.

David Janes

 

David,

You are correct in that there are 2 problems, but you can't start to
address the 2nd problem of opening the data unless you get the data
out of the Pro/I vault. Since Pro/I has all the smarts embedded in the
database, we're trying to take that out of the equation and reduce it
to a least common denominator using the dependency report. Of course
our archive will include the Pro/I database, but if we can't get it
working and/or are only looking to restore a specific version of an
assembly, the dependency report + all object report (both made just
prior to archive) will be just what we need.

Tom

 

David,

You are correct in that there are 2 problems, but you can't start to
address the 2nd problem of opening the data unless you get the data
out of the Pro/I vault. Since Pro/I has all the smarts embedded in the
database, we're trying to take that out of the equation and reduce it
to a least common denominator using the dependency report. Of course
our archive will include the Pro/I database, but if we can't get it
working and/or are only looking to restore a specific version of an
assembly, the dependency report + all object report (both made just
prior to archive) will be just what we need.

Tom

I kind of understand what you're trying to do ~ get data into a format that native Pro/e can handle. Makes me think that maybe Pro/e would be the best tool to handle the job, use it in back up mode to create the assemblies with appropriate dependencies. What's missing in the deliberations, so far, is a way to find out what products we are dealing with. For example, product glbrzh at revs A, B, C; product hglbrz at revs A-F, product zhglbr at rev A. These are all end items at their particular revision level and perhaps, from a logistics perspective, must be maintained. Intralink 'As stored' can accomplish this kind of Revision baselining, assuming you've set your top level assemblies to Released. So, in the end, what you are looking for is released assemblies that have a blank 'where used' report (meaning they're an end item). Each end item, if the Intralink releasing process was performed correctly, should behave this way. When you have the list of each end item at each release level, you can export each with 'As Stored' set. This will effectively duplicate your ILINK database on a network drive. Don't know if Pro/BATCH can handle this; otherwise it would probably be a Java script, Intralink's interface programming language. Maybe that's exactly that's what you're for. But, I suspect that there's a built in, single button function, when properly set up, that can do what you want. While I can't tell you what that is, I think that's what you should be looking for in Intralink.

David Janes