Aras losing data

Hi Riaan,

hard to tell. It´s already a good start that you found hints regarding rollbacks. 

Does the data loss affect all ItemTypes or just CAD?
Does it happen randomly or on a regular basis?
Does it happen at certain times a day?
Is your CAD interface (if CAD is mostly affected) used by multiple persons at the same time?

In the past we had data loss (=data seemed to be updated but wasn´t) when database collapsed due to to many parallel connection to the SQL server. This was caused by specific file operations (e.g. display thumbnails in the grid or download of ZIP packages with many single files). In this case user noticed that database freezed. Innovator worked, but users couldn´t refresh the grid cause the file operations blocked everything. Not sure if this one fits your description. 

Hi Angela,

Thank you for being so active on the forum!

No, it is actually Parts that goes missing, the CAD and their associated files are still there. Documents does not seem to be affected.

It does happen quite randomly, some days is does not happen at all, other days quite a few times. So this makes debugging a bit of a challenge.

It happens at any time during the workday.

I am still in a test phase with this, so there is only one person using it full-time. Unfortunately he can be a bit absent-minded, which is not ideal.

I know this sounds impossible, but I think more than one generations of a part disappears. I will start comparing the database backups and see.

Even the History of the parts does not reflect the missing part revisions. This guided me to it being a SQL issue, and the possibility of transactions not being committed, but rolled back.

Kind Regards

Riaan

Which Innovator version do you use?

Properly not your reason, but we experienced it in the past: Are your affected parts really "gone", or do users just don´t see them?

It can be simply a permission issue. Or if user are allowed to use custom item numbering, they sometimes make mistakes (e.g. add leading spaces, tabs or other hidden characters, especially when the data is copy&pasted from Excel).
In this case users cannot find their parts any more or the parts may appear at the end of the list after users created them. In this case check the db if it contains recent Parts that contain unusual properties.

If the item_number (or other properties users user for searching) are corrupted, it´s also harder to find the entry in the history, cause it affects the keyed_name too. 

This issue happened so often in our environment, that I added a custom js function to a lot of Form fields just to check and remove invisible characters. 

Other ideas:

Do you use federated data in your ItemType or in ItemType relationships? Or in secondary ItemTypes that reference to Part? There are some scenarios where federation can block other functions from being executed.

The Part ItemType by default executes a lot of side Methods, especially in the relationships. It can happend that some of them are not executed due to errors but users don´t notice that something went wrong. So it´s really important to catch every possible error. I remember sometimes LifeCycle "Post" methods or some secondary Methods in "Part BOM" weren´t executed, but no error message was thrown. 

Hi Team,

I have finally discovered the reason for the data loss of one of users of my CAD integration tool.

For future reference, here is the scenario, that led to it:

1) A part exists in Aras without CAD.

2) The user opens the Part in Aras, sees that there is no CAD attached.

3) He opens the CAD integration tool, which is a C# application.

4) Loads the file from CAD to Aras, also adding some extra fields, like design notes.

5) Closes the integration tool.

6) Goes back to Aras and adds some more stuff to the Part, for example linking a document.

7) Tomorrow morning opens the Part, and the CAD is missing!

...........The issue came that in Step6, he did not refresh the Part in the browser and edited the previous generation of the part, the one before the CAD was added. Aras did not commit the CAD work and he was left with only the Step6 generation of the Part.

The only solution which I can think of at the moment is user training.

Such a simple issue that led to a lot of sleepless nights!

Aras does some checking on the validation for locking in the method: cui_command_lock_item_can_exec

But this does not pick my scenario up as a problem. I have played around with adding a check in this method, but it is being called multiple times whilst loading a form, so I am leaving that alone for possible performance issues.

Instead I have added some code in: cui_command_lock_item_execute

This only gets called just before edit. I am able to catch out-of-date items quite successfully in there, and then handle it.

I am still doing testing, but it seems to be working.

Many thanks for sharing your insights! That´s a very interesting scenario that can happen to all of us!

Out of interest – which Innovator version do you use? Based on the mentioned Method, you seem to use Innovator 14+ , but is it higher or lower than Innovator 23?

If you are below I23, your described behavior somehow fits to this issue: www.aras.com/.../warning-versioning-and-tab-pane-very-buggy-in-new-innovator-versions-are-you-affected 

You don´t have to read the full thread. But the main issue I tried to point out was, that old revisions of an item can overwrite the latest one without the user´s knowledge. This behavior in worst case could lead to severe data loss.

The issue was caused by a corrupted lock behavior and repaired in I23. In your context it sounds somewhat familiar, so I wonder if these two are connected?

Hi Angela,

After having a quick look at your Tabs issue, it could be related but I am not sure. But the outcome is the same, a version and therefore data disappears.

My problem occurred on V2023, the open version.

You can quickly check it on your own Aras:

1) Open two independent sessions, with the same part open in both.

2) Edit the part in Session 1, add a relationship or edit an attribute. Press Done to unlock the part, don't close it.

4) Edit the same part in Session 2 as well - but don't refresh it. Add some other changes than those in Session 1. Press Done.

5) Now the magic part.....refresh the part in Session 1......Only the changes in session 2 is recorded. All changes in Session 1 have disappeared.

Yes, this will lead to great confusion and data loss, because it will seemingly occur at random, and therefore difficult to trace........ask me.

But a simple script addition is all that is needed to stop it from happening.

Kind Regards

Riaan

.