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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
am working on defining a process to archive our Pro/INTRALINK 3.4/<BR>m030 vaults in preparation<BR>for future PDMLink migration efforts.<BR><BR>As part of our long term archival process, I want to avoid<BR>dependencies on the currently deployed<BR>Pro/INTRALINK application in case we need to retrieve the data 10-15<BR>years from now when operating<BR>systems and hardware will be very different.<BR><BR>I want to generate a list of all object versions in our Pro/INTRALINK<BR>3.4/m030 environment and<BR>for each object version, a list of their dependent object versions. I<BR>realize the output will be a<BR>really huge nasty file, but that's OK.<BR><BR>If you have a SQL query that can do this and wouldn't mind sharing, I<BR>would sincerely appreciate it!<BR><BR>Tom Hogan<BR></BLOCKQUOTE> <DIV>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,&nbsp;to some basic, generic&nbsp;file structure be of more use? I guess I'm just not understanding what these lists are.</DIV> <DIV>&nbsp;</DIV> <DIV>David Janes</DIV></BODY></HTML>
------=
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
are correct in that there are 2 problems, but you can't start to<BR>address the 2nd problem of opening the data unless you get the data<BR>out of the Pro/I vault. Since Pro/I has all the smarts embedded in the<BR>database, we're trying to take that out of the equation and reduce it<BR>to a least common denominator using the dependency report. Of course<BR>our archive will include the Pro/I database, but if we can't get it<BR>working and/or are only looking to restore a specific version of an<BR>assembly, the dependency report + all object report (both made just<BR>prior to archive) will be just what we need.<BR><BR>Tom<BR></BLOCKQUOTE> <DIV>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&nbsp;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.</DIV> <DIV>&nbsp;</DIV> <DIV>David Janes</DIV></BODY></HTML>
------=
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.