Upgrading Server to version 22.1? We’ve enabled the faster AMP engine by default. Read about how these system settings changes might affect you.

We’re aware of an intermittent issue with our My Alteryx login and are actively working to have the issue corrected. If you run into an error when logging in, please try clearing all cookies or accessing the community on a different browser. Thank you for your patience!

Dev Space

Customize and extend the power of Alteryx with SDKs, APIs, custom tools, and more.

Exists

KenMorrill
7 - Meteor

In many workflows I need only to check the existence of a record in a join.  When the joined object has numerous columns - the deselects have to be performed on each column.  Unfortunately - as developing if you've run the workflow and forgot to remove the right columns - you end up doing a great deal of work on all downstream selects and outputs.

 

2 solutions:

  1. Create an "Exists" tool that works like a JOIN but returns no values from the joined object; or
  2. In the Select/Deselect options - expand to "Deselect Left" and "Deselect Right".
2 REPLIES 2
MarqueeCrew
19 - Altair
19 - Altair

Dynamic Select:

- Select via a Formula

 

left([Name],6) != "Right_"

 

That will drop all duplicate fields after a join.

 

Cheers,

 

Mark

 

 

Alteryx ACE & Top Community Contributor

Chaos reigns within. Repent, reflect and restart. Order shall return.
Please Subscribe to my youTube channel.
KenMorrill
7 - Meteor

First - I hadn't noticed that there's already a DESELECT ALL LEFT and DESELECT ALL RIGHT - so that does "solve" this.

 

It took me a while to understand the response about using the LEFT function.  I'm not wanting to automatically eliminate redundant fields in the RIGHT table, I don't want any of them.  Say you're doing a quality control project and need to know from Data Source A:

 

  • Does the record in Data Source A - have a matching master data record for the field Key 1?
  • Does it also have a matching data records for the field Key 2?

Rather that JOIN the three objects, which doesn't intuitively tell the reader of the code the purpose for JOINing the two additional data objects, and EXISTS or NOT EXISTS widget would make it very easy to see that the developer is only making sure the key fields in Data Source A have referential integrity.

 

I may just write my own Macro  :-)