Showing results for 
Search instead for 
Did you mean: 

Alteryx designer Discussions

Find answers, ask questions, and share expertise about Alteryx Designer.

Broken Table Tool Column Rules - "String Variable Switched Type"

Alteryx Certified Partner

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.


broken table tool data types.PNG



broken table tool.PNG




Some fields were being cast as integers coming out of the dynamic I inserted a select tool and changed to V_String.

So now, no errors thrown and output is per below.

Hopefully this helps?



Alteryx Certified Partner

Thank you for the speedy response @RNO2!


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.


broken table tool - bad highlights.PNG


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


I hear you @dyamichael 


Based on your call-outs below, sounds like the algorithm needs tighter guardrails...


Rather than [id] = 'e' AND [_CurrentField_] < 10, please consider the below (sorry for the brute force approach)


  • So for column Sun 01, column config column rule: [id] = 'e' AND [Sun 01] IN ('0','1','2','3','4','5','6','7','8','9'); repeat for all known column specificity
  • And, for Dynamic or Unknown Fields, column config column rule: [id] = 'e' AND [_CurrentField_] IN ('0','1','2','3','4','5','6','7','8','9')



Alteryx Certified Partner

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. 


 broken table tool - bad highlights 2.PNG

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.


Sure thing @dyamichael 

I was out of pocket for a month, but I'm back now.


I will take another look...though  feels like (to your point) this might be a bug.

I'll take another go this weekend and let you know!