Hi @Soldado , just providing an alternative.
One thing I don’t like about the Table Validator is that it’s kinda restrictive, in the event that you just want to check if a couple of columns exist or not. For example:
- If you have let’s say 10 columns, and you only care about 2 columns, you are still checking for 10 columns.
- You are restricted to the structure of the reference table, which you may not want. For example, you may get columns in different column order in your case (…, RV, DZ, … vs …, DZ, RV, …). I don’t think that both structures would pass.
- In addition to #2 above, even if you have RV, DZ, you may end up with different columns for the different iterations of the loops, since you mentioned that sometimes DZ is not there, so we can assume that may be some other columns might not be there either while both RV and DZ are there. For example:
ID, Name, DZ, RV, Retired
ID, Name, DZ, RV, Address
You should be able to calculate the Date difference for these 2 records, but you can’t if you are going to use the same table structure for the Table Validator for both records.
- Sure, we can argue that we can do a column filter on DZ and RV, but you actually cannot. Isn’t that the challenge in the first place, to know if DZ and RV exist?
Don’t get me wrong, I am not saying that the Table Validator is bad. It all depends on what you need to do, and given the different cases that you mentioned, and with the assumption that you only care to know if 2 columns exist, just like a hammer is not bad, it has its purpose, but you would not use a hammer to press a pin in a sheet of paper.
So, based on this, I have prepared an alternative, which is simply to check if RV and DZ columns exist, regardless of structure.
Workflow looks like this:
And I tested with the following Data:
Test 3 (with DZ missing):
This time, the IF Switch will route to the bottom:
The Constant Value Column is just adding 0 as Performance:
Of course, you can process this case as you want.
Here’s the workflow:
Check if columns exist.knwf (39.7 KB)