Managing Errors During Data Saving

• Analyze the error to determine what actions are appropriate.
• Launch the save process again, once the origin of the error has been found and removed.

• If the Instance Name of a component is too long, a message appears: "Instance name xxx /p1 is too long (> 40 characters). Please rename it as Instance names impact Multi Models Links."

  The Instance Name whose length is more than 40 characters is no longer truncated automatically at save for 3 reasons:

  • The Instance name is used by MML (Multi Models Links): when an Instance Name was truncated and involved in an MML, the MML was broken when reopening the assembly, because MML use the Instance Name's path. Now, if you modify the Instance Name, the MML can retrieve its targeted geometry when using publications.
  • You cannot have two instances with the same name under one "father" in CATIA V5. When truncation was done under 2 instances under the same father, therefore these 2 instances had the same name at the end. In ENOVIA, under the same father Product, you can see several Instances with the same Instance Name but in CATIA it is forbidden (a message appears when you try to add or rename two Instances with the same Instance Name). When importing two Part Instances with the same Instance Name into CATIA (under a common father), the first Instance was created in CATIA without any problems but the second one was automatically renamed by appending the character "#1" into brackets to its name, which made the import possible. As a result, the instance name was no more stable and it was difficult to identify the instance in session. You should not use this session to add links to the parts containing #1, because Technological Packages links for instance would be inconsistent.
  • Semantic loss: the user often gives semantics to the Instance Name (specially for long names) and automatic truncation erased this meaning.

To get round the problem, we suggest you to:

• Recreate data with a newer level of CATIA software.
• Use the Copy / Paste Special > Break Link functionality to minimize the workload.

CATIA restores data in case of severe error:

In all cases where the save process encounters a severe error, data is restored in the same state as before save was requested:

• No data is changed in the ENOVIA database and the Vault (storage medium).
• The ENOVIA server session is reset and ready for a new save operation.
• The CATIA client session is reset and ready for a new save operation or any other recovery interaction.

Messages:

An Incident Report window displays the list of failure messages corresponding to the unsuccessful steps in the save process.
The exact contents of this window can vary depending on the scenario.

Example 1:

This message has to be interpreted in the following way: A severe error has occurred, the save operation is not performed. The error occurred while saving the document "drtPlan2". The save process failed because of a problem in the ENOVIA V5 VPM Vault (this will help the database administrator to fix the problem). The user is informed that all recovery actions have been performed successfully. In this example, all data have been restored in the ENOVIA V5 VPM database and in the CATIA V5 session. If it is not the case, the users need to save locally their CATIA V5 session and try again once the problem is solved. For more information about this Saving operation, please refer to the following chapters: Saving Existing Documents, Saving All Documents and, Managing Document Save in the CATIA - Infrastructure User's Guide.

Example 2:

The position matrix changes when moving an instance (during a move operation or when adding an offset constraint for instance). Saving this instance update the position matrix. But the Save operation may fail for two reasons:

• security rules: the user does not have move permissions.
• the moved instance or its parent is not locked by the current user:
  • if the moved instance is unlocked, a message is displayed,
  • if the parent is unlocked, no message is displayed and the Save operation completes.

Example 3:

This message "Failure when saving object xxx in ENOVIA Data Base" is displayed when the problem is general and non-identified: the object cannot be saved and therefore all the objects that depend on it cannot be saved as well.

Categories of Errors when saving Data:

When a CATIA V5 Session is Saved In ENOVIA V5 VPM, some errors may occur and, in this case Warning messages are conveyed to the user accordingly. Here are some examples of errors:

• a problem of connection with ENOVIA (the ENOVIA server may stop when the machine shuts down for instance),
• a problem of connection with the Vault,
• a problem related to Security / LifeCycle / or Lock:
  • Security: when the user does not have the rights to perform the operation involved during the Save transaction. For instance: Add a child instance under a PRC, or modify a geometry.
  • LifeCycle: when the object's current status does not allow to save it. Example: If the object is in Released status, it cannot be modified and, hence saved in ENOVIA V5 VPM.
  • Lock: when the object modified by the current user is not locked or locked by another user, the object in question will not be saved.

  • In case a Save operation failed due to security privilege, an error message displayed in VPM Navigator. This message gives information about which P&O process is not granted to the current user. In other words, the couple [Entity, Process] will be explicitly mentioned so that the user will have accurate information on the exact missing P&O process, as given below in the screenshot.

    

Limitation

All P&O processes that are currently checked by CV5-EV5 integration code for load and save operations will show the error message. Whereas, other processes, which are not currently supported will remain as such. For example, the processes AddModificationHistory and AddAffectedObject dedicated to configured operations and checked by ENOVIA server code at save time will not show the error message. 

Protocol:

One important aspect related to this enhancement is to convey error information appropriately to the end-user so that it will be easy for him/her to figure out what corrective action to undertake to preserve data consistency.

Operations types vs. rules:

The rules to be checked depend on the type of the operation which has to be performed for a given object. The table below describes for each operation (left column), how the different verifications are undertaken and which data is involved:

If you use the setting CV5EV5_ADD_WITHOUT_PARENT_LOCK, it allows you to deactivate the check upon the lock of the parent object, that is to say you can add a part even if the parent is not locked.

Note: the check deactivation is only applied to the Add (or New) operation - for this reason, the setting is called CV5EV5_ADD_WITHOUT_PARENT_LOCK - and not to the other operations Modify / Delete / Replace / Move.

1. not save the object, and ignore the operation,

2. guarantee database consistency. In particular, if other operations are related to the one that is not saved because of the above rule, these other operations will not be saved either (see figure below).

3. notify the end-user about all the operations / objects which will not be saved in ENOVIA V5, and for what reason.

Data flow:

For each type of operation, specific data are passed in to perform the corresponding verification. The result of the check, is captured, specifying whether the applied rules are fulfilled or not.

Here is the description of the different rules:

Two alternatives are then possible for the user:

1. Accept a partial Save of his work by closing his CATIA editor and losing his not saved modifications.

2. Do the adequate actions in ENOVIA (for example: locking the part) and use again the command "Save in ENOVIA V5 VPM" to save the not saved yet modifications.