This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
This issue, alongside others, has had me losing hair for weeks now-- I don't know if I'm missing something or if there's a major bug in the Table Tool.
This is part of a bigger workflow. In a nutshell: this part starts with a table of IDs, dates, and hours worked that are cross-tabbed into a sorted list of dates. They are dynamically renamed then a table tool makes a table with some highlight rules.
The table tool has a column rule on Dynamic or Unknown Fields. The rule is a formula to highlight on this example condition:
[id] = 'e' AND tonumber([_CurrentField_]) <10
The dynamic rows from the crosstab were removed and re-added to clear the table cache and apply the rules to each of those dynamic fields.
When run, an error is thrown: "String variable switched type". Below is a screenshot of the metadata in the connection just before the table tool.
This is just the current blocking error with the Table Tool. There is another one behind this one's resolution regarding highlights being made to the wrong dynamic fields' cells with no discernible logic when using a formula column rule.
While the fields should be numeric for the formula, we can deduce that the table tool doesn't play nice with formula column rules on numeric fields. As a precursor to this, using [id] = 'e' AND [_CurrentField_] <10 lead to the same error for some reason: "String variable switched type".
Anyways, we'll chalk it up to an Alteryx quirk where numeric data types need to be converted into string datatypes then cast tonumber() when running them through a table tool column rule formula to get it to work.
The problem is that the highlighting doesn't really work, and this is crux of the issue. Screenshot below with the problem cells highlighted.
It looks like the formula causes highlights that make no sense.
I attached the workflow with the first two broken setups and the third setup that now returns broken highlights:
1. A number used in a column rule formula
2. A number cast to a number in a column rule formula
3. A number converted to a string to be cast to a number in a column rule formula
Thanks for taking the time to brute force this @RNO2
The issue with hard-coding column names like [Sun 01] is that all columns are dynamic all the time, so using [_CurrentField_] is necessary.
When trying to use your solution with [id] = 'e' AND [_CurrentField_] IN ('0','1','2','3','4','5','6','7','8','9') for all columns (test 5 in the attached), the highlights were broken again with the result below.
This leads me to believe that the issue is with the [_CurrentField_] variable in the Table tool (it looks like it might be offset one field down? That was my best guess for the pattern in the actual workflow as well). I tested the same formula on the [_CurrentField_] variable in the multi-field formula tool and it works correctly.
I then tested building the string for the fieldname in the formula (test 6 in the attached) as [id] = 'e' AND "["+[_CurrentFieldName_]+"]" IN ('0','1','2','3','4','5','6','7','8','9') with no luck-- Alteryx seems to interpret it as a string.
Looks like this might be a bug to bring to support.