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.
1 Use an IN statement, it saves writing lots of ORs
2 best practice is not to use hard coded values as it can be difficult to trace any errors or unmatched values if the underlying data changes. Instead a lookup table and a join is a better option. Values that join meet the condition and you can then add the eligible flag, values that don’t join and come out on the left output (assuming the main data is the left input) don’t match and can have another flag, and data coming through on the right output are things that don’t match with the lookup table and might be a sign of an incomplete data extract.
here is a post should how joins can be used as filters.
I'm in agreement with you about avoiding "hard coding" values within the workflow. But I want to voice a couple of (hopefully) agreed amendments to your statement about joins.
When running large sets of data through the "lookup" routine, it is better to use a FIND REPLACE tool than a join. The FIND REPLACE tool is better because:
It doesn't sort the "Large" set of data.
It permits for case-insensitive joins.
When using a FIND REPLACE, you should append the lookup field to the original data. This "new" field is either NULL() or contains the value found. You can then FILTER (Filter is much faster than a JOIN) the results to those that are or are not found.
That is a "more-better" solution than simply using a JOIN.
Alteryx ACE & Top Community Contributor
Chaos reigns within. Repent, reflect and reboot. Order shall return. Please Subscribe to my youTube channel.
Thank you very much for your help! I was looking to add a column of "Type" because the other Input Data had this column included. This is definitely something I will use in the future a lot and found really helpful.
Thank you very much for your help! Sadly, even with replacing the "==" with the correct syntax, it did not change the issue. I definitely appreciate your feedback though and will make sure to use the correct syntax going forward.