Managing Errors During Data Saving

Example 1:

	In the event of an error during the process of data saving into ENOVIA V5 VPM from CATIA V5 the user and the site administrator need to: 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.
	CATIA Part Numbers, Instance Names, Publications and Attributes should not contain DBCS characters (kanji characters, etc...) if saved in ENOVIA V5 VPM, unless you set the CV5EV5_DBCS_NAMES variable to TRUE on the LCA server side. Yet, CATIA attribute names and ENOVIA V5 VPM document names cannot contain DBCS characters. Moreover, the CV5EV5_DBCS_NAMES variable does not provide National Language Support for attribute values. Such values, for example, LCA system attributes such as In Work, Approved, Released, etc. remain unchanged in relation to the database.
	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.
	Two Tech Packs with the same name can be saved in ENOVIA without any name change.
	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 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.

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,
• 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.
  
  The error message displays the name of the lock owner in the Impacted object section of the error message.

• 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 following 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:  

Operation	Process granted	Lock objects	Lifecycle Status
New	1. Add PRC under a PC: AddChildProductRootClass 2. Add a Group under a PRC: AddChildProductComponent 3. Add a Part under another Part: AddChildPartInstance	1. None   2. None     3. Parent must be locked (*)	1. Parent not in final status 2. Parent not in final status 3. Status of parent (instance &  reference) must be updateable (digit 1) and not Released (digit 5)
Modify	Modify	Object locked	Status of parent (instance & reference) updateable and not Released Object status can be updated
Delete	Delete	- Parent locked - Object locked	Status of parent (instance and  reference) is updateable and not Released Object status can be deleted
Replace	Replace	Object locked	Object status can be updated

(*) Default behavior: If you want to add a part under a product (Instance and Reference), the product must be locked. And if it is not the case, a warning is displayed.

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.   In all cases, if one of the rules is violated for a given operation (create, modify, etc) and object, the system should:

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:  

Operation	Description
All	Everything is ok Failure occurred during execution
New	No privilege for the secured process Parent not locked Parent locked by someone else Parent status not updateable Parent status is Released
Modify	No privilege for the secured process Object not locked Object locked by someone else Object status not updateable Object status is Released
Delete	No privilege for the secured process Parent not locked Parent locked by someone else Object not locked Object locked by someone else Parent status not updateable Parent status is Released Object status cannot be deleted
Replace	No privilege for the secured process Object not locked Object locked by someone else Object status not updateable Object status is Released

  From the user-interface perspective, new error messages will show up when a rule is violated for a given operation. In this case, the objects impacted by the rejected operation will not be saved.

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.