We all know that VLOOKUP can find first match and return the results. But what if you want to VLOOKUP multiple matches? Use this simple trick instead.
Multiple matches in Excel lookups
The problem is simple as illustrated below. Say you have a bunch of dates & locations. You want to find out corresponding date(s) for a location. If you use either VLOOKUP or INDEX+MATCH, you just get the first date, but you want them all.
In new version of Excel (2019), you can use awesome formulas like FILTER() to do exactly this, but most of us are still stuck in older version of Excel. So how to get all the matches?
The trick – Use TEXTJOIN…
TEXTJOIN is a text combining function available on Excel 365. We can it to solve our multiple matches problem.
Let’s say our data is in a table named plan. We want to lookup the location in cell G7 and return all matching dates.
We can use below TEXTJOIN formula (you must press Ctrl+Shift+Enter) to get result as this is an array formula.
=TEXTJOIN(", ",TRUE, IF(plan[Location]=G7,
TEXT(plan[Date],"dddd dd-mmm"),""))
How this multiple match formula works?
Let’s go from inside out.
- IF(plan[Location]=G7 this part checks every location in the plan table and returns a bunch of TRUE or FALSE values. The end result would be an array like this. {FALSE;FALSE;FALSE;FALSE;FALSE;FALSE;FALSE;FALSE; TRUE;TRUE;TRUE; FALSE;FALSE;FALSE;FALSE;FALSE;FALSE;FALSE;FALSE}
- TEXT(plan[Date], “dddd dd-mmm”) this part takes all the dates in plan table and converts them to dddd dd-mmm format (ie 18/05/2019 becomes Saturday 18-May). The end result would be another array of dates formatted.
- IF(plan[Location]=G7, TEXT(plan[Date],”dddd dd-mmm”),””) this entire IF formula results in either a bunch of formatted dates or blanks, based on whether plan[Location] matches G7 or not. So we get something like this. {“”;””;””;””;””;””;””;””;”Saturday 18-May”;”Sunday 19-May”;”Monday 20-May“;””;””;””;””;””;””;””;””}
- TEXTJOIN(“, “,TRUE, IF()) this is the final part of the puzzle. TEXTJOIN takes individual bits of the array in #3 and combines them with delimiter , (comma space) but ignores any blanks (TRUE as second parameter). The final result is one text that goes like – Saturday 18-May, Sunday 19-May, Monday 20-May
Why bother with TEXT(plan[Date], “dddd dd-mmm”)?
If you don’t use TEXT() to convert your dates, you get something like this instead – 43603, 43604, 43605. This is because Excel dates are really just numbers. So when you use them in any formula you just get the underlying number value. This is why TEXT() formula is so helpful.
Related: Top 10 tips for working with Excel date & time values.
Still confused? Multiple Matches in Excel – Trick
Not sure how all of this works? Check out below video to understand this trick in detail. You can also watch this on my YouTube channel.
Download VLOOKUP Multiple Matches workbook
I made an example workbook with this formula technique. Click here to download or see this in action online here.
HELP! I don’t have TEXTJOIN()
As mentioned earlier, TEXTJOIN is available in Excel 365 or 2019 + only. So if you are using an older version of Excel, you should use one of the below techniques to get multiple matches.
And yeah, while you are polishing your lookup saw, why not also read these..
How do you multiple match?
Do you use TEXTJOIN() or something else? Or do you just give up after first match? Please share your lookup tricks in the comments box.
One Response to “SQL vs. Power Query – The Ultimate Comparison”
Enjoyed your SQL / Power Query podcast (A LOT). I've used SQL a little longer than Chandoo. Power Query not so much.
Today I still use SQL & VBA for my "go to" applications. While I don't pull billions of rows, I do pull millions. I agree with Chandoo about Power Query (PQ) lack of performance. I've tried to benchmark PQ to SQL and I find that a well written SQL will work much faster. Like mentioned in the podcast, my similar conclusion is that SQL is doing the filtering on the server while PQ is pulling data into the local computer and then filtering the data. I've heard about PQ query folding but I still prefer SQL.
My typical excel application will use SQL to pull data from an Enterprise DB. I load data into Structured Tables and/or Excel Power Pivot (especially if there's lot of data).
I like to have a Control Worksheet to enter parameters, display error messages and have user buttons to execute VBA. I use VBA to build/edit parameters used in the SQL. Sometimes I use parameter-based SQL. Sometimes I create a custom SQL String in a hidden worksheet that I then pull into VBA code (these may build a string of comma separated values that's used with a SQL include). Another SQL trick I like to do is tag my data with a YY-MM, YY-QTR, or YY-Week field constructed form a Transaction Date.
In an application, I like to create a dashboard(s) that may contain hyperlinks that allow the end-user to drill into data. Sometimes the hyperlink will point to worksheet and sometimes to a supporting workbook. In some cases, I use a double click VBA Macro that will pull additional data and direct the user to a supplemental worksheet or pivot table.
In recent years I like Dynamic Formulas & Lambda Functions. I find this preferable to pivot tales and slicers. I like to use a Lambda in conjunction with a cube formula to pull data from a power pivot data model. I.E. a Lambda using a cube formula to aggregate Accounting Data by a general ledger account and financial period. Rather than present info in a power pivot table, you can use this combination to easily build financial reports in a format that's familiar to Accounting Professionals.
One thing that PQ does very well is consolidating data from separate files. In the old days this was always a pain.
I've found that using SQL can be very trying (even for someone with experience). It's largely an iterative process. Start simple then use Xlookup (old days Match/Index). Once you get the relationships correct you can then use SQL joins to construct a well behaved SQL statement.
Most professional enterprise systems offer a schema that's very valuable for constructing SQL statements. For any given enterprise system there's often a community of users that will share SQL. I.E. MS Great Plains was a great source (but I haven't used them in years).
Hope this long reply has value - keep up the good work.