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
Reply to
Tom
Loading thread data ...
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
Reply to
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
Reply to
Tom

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.