Important information regarding an issue using Pro/ENGINEER Wildfire 5.0 with Windchill 9.1 and Pro/INTRALINK 9.1
Title Family Table Objects Created Or Last Saved In Wildfire 4. 0 Or Earlier Releases And Subsequently Modified With Wildfire 5. 0 May Show Inconsistencies In Family Cell Values And May Prompt To Check Out The Entire Family Table.
Details
Description
Starting with Wildfire 5.0 in combination with Windchill Solutions 9.1 M020 or later, PTC introduced the ability to map Pro/ENGINEER attributes to Windchill instance based attributes (IBA's) with units (prior to Wildfire 5.0, Pro/ENGINEER attributes had to be mapped to unitless Windchill IBA's). As a result of this change, all family table cell values which have dimensions are stored in Windchill in the corresponding base units of the SI standard (International System of Units; e.g. length will be stored in meters).
Family table objects created or last saved in Wildfire 4.0 or earlier releases and subsequently modified with Wildfire 5.0 may show inconsistencies in family table cell values. Attribute values displayed in Windchill, values listed in Windchill Related Objects > Family reports and family table cell values in Pro/ENGINEER may have units and values changed to SI or values changed by SI conversion factors. Modification of the family table may also prompt the user to check out the entire family table.
Resolution
Pro/ENGINEER Wildfire 5.0 M050 includes a fix that will require the entire family table to be checked out when a user initially modifies any member of a family table that was previously created using an earlier version of Pro/ENGINEER (e.g. Pro/ENGINEER Wildfire 4.0). The subsequent checkin of the entire family table will ensure that the entire family table is updated in Windchill. Family table values will be converted to SI units, but all members of the table will now be consistent and correct.
Customers using Pro/ENGINEER Wildfire 5.0 and any Windchill-based solution (PDMLink, ProjectLink, INTRALINK 9.1) are strongly recommended to upgrade to Pro/ENGINEER Wildfire 5.0 M050 in order to avoid creating incorrect values in family tables.
A .zip file is available to help with this issue and it includes the following:
1) A script (detect_1964773.sql) that can be used to help determine if a Windchill system has been affected by this issue.
2) An executable file (detect_1964773_ft_table_generator.exe) that will convert the output of the script into a easier to understand form.
3) A document (Steps to execute the script.docx) which contains instructions to run the script and executable mentioned above as well as a recommended procedure for correcting data issues.
The .zip file can be found here: http:/ / www. ptc. com/ view?im_ dbkey=114939
Alternate Technique
When needing to modify a legacy family table, check out the entire family table, perform the desired modification, make a change to the generic to ensure the entire family is modified (e.g. add/delete a datum in the generic), verify (optional), save and check in. This will update all instances of the family to be Wildfire 5.0 compatible.
Additional Information
The following are several scenarios to be aware of, their resulting consequences and recommended practices for avoiding data inconsistencies.
Case #1: New family table data created in Wildfire 5.0
In such a case, inconsistencies do not occur as all dimension or parameter with unit driven family table values are stored in SI units.
Case #2: Complete Family Table save of legacy Family Table data in Wildfire 5.0
In such a case, inconsistencies do not occur as all dimension or parameter with unit driven family table values are stored in SI units.
Case #3: Legacy family tables having column items other than non-designated dimensions or non-designated parameters with units
In such a case, inconsistencies do not occur as there is no conversion to SI units.
Case #4: When the check in of the generic fails after partially checking out legacy instances, the user has the option to check out the unmodified instances via embedded browser check out action or via File> Check In> Custom Check In from the Pro/ENGINEER File menu
In such a case, an explicit save in Pro/ENGINEER session is not automatically carried out for the instances and neutral data conversion doesn't occur for instances. The unmodified instances may see inconsistencies. To avoid such a situation, any modification of a family table should include the complete check out of the family, save and then a complete check in of the family.
Case #5: When merging a deleted instance(s) back into the latest iteration of the family
In such a case, inconsistencies may occur. To avoid such a situation, any modification of a family table should include the complete checkout of the family, save and then a complete check in of the family.
Как увидеть ссылки? | How to see hidden links? - ссылка на скрипт