Skip to main content
Nintex Community Menu Bar
Solved

Random data loss in repeating section

  • September 10, 2021
  • 12 replies
  • 169 views
  • Translate

Markus-Marines

Hi,

I've created a Form with a repeating section. This section is connected to a multiline plain text field. The form itself, is edited multi times, by multi users. After the form is saved (New & Edit), a workflow is activated. So far so good. But randomly, the data in the repeating section is lost. First I thought that it was happened by the controlsetting Disable the control when the user is not 'the owner'of the repeating section line. But when I remove this setting, the problem still remains. The whole section is in a Panel and that one is Disabled after a particular Status. Its driving me mad. Am I doing something wrong, or is it a bug? The version of Nintex is 5.2.1.30.

Best answer by Markus-Marines

I think I found the cause! In the Form I use Panels inside Panels. I do think that is not the problem, but when I add a rule on the ‘upper’ panel with the ‘Disable’ action and I do the same on a ‘inside’ Panel, then the data get lost.
Maybe it is a bug, or it’s by design, but for now I can go further.
View original
Did this topic help you find an answer to your question?

12 replies

allan
Forum|alt.badge.img+9
  • Rookie
  • 177 replies
  • September 13, 2021

Do you save your repeating section in a multilines of text field (plain text)  ?
Do you lose your data when displaying the repeating section on a form ? If this is the case, check that your repeating section is correctly connected to your multilines field, and that every control has the correct name (the same as the initial form).

Translate

Markus-Marines

Hi Allan,

 

Yes, the section is connected to a multiline plain text column. And yes the data is also loss in view mode. But the weird part is, that the loss is random. Not always after the first save. What do you exactly meant with "every control has the correct name"? See the screenshot.

Translate

allan
Forum|alt.badge.img+9
  • Rookie
  • 177 replies
  • September 14, 2021

What I meant was : 
If you have a repeating section on your init form, and you want to display/edit this repeating section in a flexi task, then you must connect your plain text field to the repeating section, but also be careful that each control has a name in each form and that they are the same.

The value stored should be something like that :

<?xml version="1.0" encoding="utf-8"?><RepeaterData><Version /><Items><Item><FirstName type="System.String">Allan</FirstName><LastName type="System.String">Hub Collab</LastName></Item></Items></RepeaterData>
Translate

Markus-Marines

Ok, I understand, but that is not the issue. The Repeating Section is on the same form and loses the data randomly. I do think that the Controlsetting 'Enabled' had to do with it, but I thought that Enabled=No, is a protection feature.

Translate

allan
Forum|alt.badge.img+9
  • Rookie
  • 177 replies
  • September 14, 2021

What I advise, instead of setting "Enabled=No" is to have a rule to disable the repeating section.
I do know that I faced some issues back in the day when using Visible or Enabled instead that rules (that are more versatile).

Translate

Markus-Marines

I did used a rule for this purpose, but ran into the same problem. That's why I did it on Control level. Could it be possible that the form is corrupted? 

Translate

allan
Forum|alt.badge.img+9
  • Rookie
  • 177 replies
  • September 14, 2021
It's very unlikely, to be honest. Do people edit the form before losing data or is it just sitting still and the data disappears ?
Have you tried to enable the versioning on your list and have a look on the history version of the item corrupted ?
Translate

Markus-Marines

Of course, I've enclosed a screenshot of a part of the version history

Translate

MegaJerk
Forum|alt.badge.img+14
  • Scholar
  • 832 replies
  • September 18, 2021

It seems that you've disabled the control if it isn't the "owner" of the form so you shouldn't be getting any data loss from something like a Race Condition (two people have the form open at roughly the same time and save different snapshots of data at roughly the same time resulting in the loss of *one* set of data), and besides, you would have likely gotten a warning from sharepoint had that been the case.

 

My only thought would be that maybe it's something in your Workflow. Is this something you can replicate in a test form / item that only you yourself will be messing with? If so, I would have your workflow send you the contents of the column before and after it has finished processing to see if they are the same. 

 

That would at least narrow it down to whether this is something happening before it gets to WF or during. 

Translate

Markus-Marines

Hi Megajerk, 

 

Thanks for your thought. I've disabled the workflow from running and edit the item different times to see if the data get lost. And yes, even without the workflow, the data was lost. So my conclusion is that it is in the Form (design?). And I still do not no why. (And I am not a newbie:-) )

Translate

Markus-Marines
I think I found the cause! In the Form I use Panels inside Panels. I do think that is not the problem, but when I add a rule on the ‘upper’ panel with the ‘Disable’ action and I do the same on a ‘inside’ Panel, then the data get lost.
Maybe it is a bug, or it’s by design, but for now I can go further.
Translate

allan
Forum|alt.badge.img+9
  • Rookie
  • 177 replies
  • October 20, 2021

Wow, it was indeed a strange issue.
I think I can confirm this is the correct issue. To be honest, a colleague asked me about the same issue 2 days ago (controls becoming empty because the panel they are in is disabled).
It did not occurred to me that you had the same problem since your post was from a month ago.

I solved the issue by disabling the controls directly and not the panel. You should try that 😉 

Translate

Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie Settings