Community Spring Cleaning week is here! Join your fellow Maveryx in digging through your old posts and marking comments on them as solved. Learn more here!
The Product Idea boards have gotten an update to better integrate them within our Product team's idea cycle! However this update does have a few unique behaviors, if you have any questions about them check out our FAQ.

Alteryx Designer Desktop Ideas

Share your Designer Desktop product ideas - we're listening!
Submitting an Idea?

Be sure to review our Idea Submission Guidelines for more information!

Submission Guidelines

stop table tool from losing xml

As pointed out by @Joshman108 in this post, you can lose some/all of your work in the table tool if the metadata is ever not flowing correctly. Losing your metadata can happen for a number of legitimate reasons (copying/pasting, crosstab tool upstream, python tool upstream etc.) There are a number of tools (including the table tool) where losing the matadata can prove catastrophic. 

 

Consider these 2 simple examples:

1) We have the dynamic box checked and apply a rule to field 1:

patrick_digan_0-1614630683908.png

If our table tool loses its metadata, our row rule is completely erased! I would expect the tool to remember our row rule once metadata is reestablished.

 

2) We have the dynamic box unchecked, as well as Field4 unchecked. We setup the same rule as before that references field4.

patrick_digan_1-1614630825241.png

Now when the metadata is lost and restablished, the table tool does a good job of remembering that Field4 is supposed to be unselected, and that I had a rule for Field1; however, the rule has now been changed! I would expect the rule to also remember that I was referencing Field4. Note that if my rule had reference a field that was included in the table, it would have remembered the rule. It's only because my rule referenced Field4 which was not included in the table that my rule got messed up. In my rule, it now references Row# which is completely wrong:

patrick_digan_2-1614630933228.png

 

 

 

3 Comments
Joshman108
8 - Asteroid

I am in full support of this. I have spent a full 5 workdays trying to understand this was an issue and scope out the extent of this issue in a workflow of ours. I have then had to 1) Extensively document how to fix the error once a workflow loses table configuration 2) Create a python script to fix the errors at scale

 

This shouldn't be necessary. 

SeanAdams
17 - Castor
17 - Castor

This would solve a lot of pain when you're working in the early stages of a data set and the data is changing shape.

 
AlteryxCommunityTeam
Alteryx Community Team
Alteryx Community Team
Status changed to: Accepting Votes