Skip to main content
Nintex Community Menu Bar

It was recently brought to my attention that older submissions of a Nintex 2016 form have lost data from a repeating section.  The last modified date on the items is well in the past so I don't think a user overwrote the data.

 

The only thing I can think of is that I named a pre-existing control in the repeating section on the form.  Would this cause this kind of data loss?

 

Thanks in advance!

Yes. Making a change to a control's name can indeed cause you to lose data. However, depending on whether or not you've actually saved the form since the control was changed, the data might still exist. 



 



An example



 



I have a Repeating Section with 4 controls in it, and I'm going to change the name of one of the Controls from "control_Qty" to "control_Qty2":





 





 



I had an item already on the list that had a Qty of 20:





 



it's XML looked like:



<RepeaterData>

<Version />

<Items>

<Item>

<control_Fruit type="System.String">1</control_Fruit>

<control_Qty type="System.String">20</control_Qty>

<control_Price type="System.String">1.50</control_Price>

<control_SubTotal type="System.String">30</control_SubTotal>

</Item>

</Items>

</RepeaterData>


 



However, after publishing the form, and looking at that Item again, I see that I am now missing a value for a Qty:





 



HOWEVER, if I were go back into the Form and change that name BACK to "control_Qty", after I published it, assuming nobody has messed at all with my item, that data would, for lack of a better term, come back. 



 



Why? Because the XML that is being used to rebuild the form (in either View or Edit mode) is relying on the control names to know where to put the values. Changing the name of a control does NOT update the XML for the Repeater Section, so when there is a mismatch, it just drops the value. 



 



But let's say that you needed change that Control's name to something else. Well if that's the case, then I would create a workflow that goes through and simply updates the XML of the Repeating Section in question so that the old Control name is converted to the new one. 



 



Using our above example and going from "control_Qty" to "control_Qty2". We know that if we have the following XML:



<RepeaterData>

<Version />

<Items>

<Item>

<control_Fruit type="System.String">1</control_Fruit>

<control_Qty type="System.String">20</control_Qty>

<control_Price type="System.String">1.50</control_Price>

<control_SubTotal type="System.String">30</control_SubTotal>

</Item>

</Items>

</RepeaterData>


 



Then the item will not show the Qty value of 20 because we've changed the control name. If I make a little workflow with a Query XML action:





 



And configure it as shown:





 



Using the following XSLT:



<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">



<xsl:template match="@*|node()">

<xsl:copy>

<xsl:apply-templates select="@*|node()" />

</xsl:copy>

</xsl:template>



<xsl:template match="control_Qty">

<control_Qty2>

<xsl:apply-templates select="@*|node()" />

</control_Qty2>

</xsl:template>



</xsl:stylesheet>


 



Then it will take the existing XML, look for any node named "control_Qty" and will update it to "control_Qty2", resulting in the following XML:



<RepeaterData>

<Items>

<Item>

<control_Fruit type="System.String">1</control_Fruit>

<control_Qty2 type="System.String">20</control_Qty2>

<control_Price type="System.String">1.50</control_Price>

<control_SubTotal type="System.String">30</control_SubTotal>

</Item>

</Items>

</RepeaterData>


 



Which I can then save back to the item using an update:





 



Running this on the item results in my missing data reappearing!





 



The Big Catch



 



That isn't to say that you can't permanently lose data! If you have made a change to a control name, and then someone edited a form and saved it before this has been done, then the lines of xml that point to controls no longer there will be discarded along with any associated values!



 



There is not much you can do in that case, but you can at least prevent further problems by either using the method above or reverting the control's name back to what it used to be. 



 



I hope that this helps you with this issue. 



 



 



 



 


Thanks for the info! It makes sense.  Unfortunately I already saved the form changes.  I'm going to work with our farm admin to restore the list from backup, then I'll look into the workflow method you suggested. 



 


Excellent. Please mark this thread as solved if you are satisfied that your initial query has been answered. 

Let us know if you have any more questions once you've reached that restoration point. 


Reply