# Something I never got about the Design of VLookup



## Oorang (May 30, 2008)

Why does vlookup use the Column parameter? It's so unnecessary. It can only retrieve from one column. So so why would you ever define a table as wider then that lookup column? It should just automatically pull from the rightmost column of the defined lookup table. Every time I count the columns in a table I think to myself what a waste of time! Is there some utility that I'm missing where it might be helpful to define a table 6 columns wide, lookup from the 1st column, pull from the 3rd column, and just have the other 3 there for moral support?


----------



## schielrn (May 30, 2008)

I agree with you very much on that. I feel that they missed the ball by not having an option to look to the left with the formula rather than having to use index/match. Have the furthest column right be what you are looking up and enter a negative column. If the number is negative it uses the column K as lookup and if it is positive it uses D as lookup:

=vlookup(A1,B:E,4,0) would match A1 in column B and return the value in E

OR

=vlookup(A1,B:E,-4,0) would match A1 in column E and return the value in B

That gave me an idea for a little UDF.

But it does make it nice when copying the formula across a range and have the column number increment.

=vlookup($A1,Sheet2!$A:E,column(E:E),0)

Then drag the formula over to column D and have:

=vlookup($A1,Sheet2!$A:I,column(I:I),0)

But the column would still be irrelevant if you always had your lookup reference the correct last column.


----------



## NateO (May 30, 2008)

The real question is why do people insist on feeding VLookUp() a Range that's bigger than the vector they eventually want to pull from? Let's fire as big of an array into memory as possible, necessary or not?

Index(Match()).


----------



## DreamAlchemist (May 30, 2008)

Perhaps I am not understanding what you are asking, but I find the Vlookup to be fine.
I have a spreadsheet with 20 columns of data each row being an inventory item from size, to quantity, to pricing. On another sheet I can write one formula referencing the table copy it everywhere and just modify which column to return. Which is not always the rightmost column.


----------



## Jonmo1 (May 30, 2008)

Very interesting discussion. AS schielrn pointed out, you can start with a 2 column lookup array, and as dragged right it expands as needed.

=vlookup(a1,$E:F,Column(B1),False)

as dragged right, the array and column ref adjust accordingly.

However, I can see the need for it if you use Named Ranges. You can't expand the columns of the array when dragged right using a named range..So it would be necessary to use the entire range, and specify column ref.

But I think at the very least it could be made an OPTIONAL argument. If omitted, it uses the far right column. At least that's what I did in my VlookupNth UDF.


All arguments aside, Index/match is probably the better solution than vlookup anyway...


----------



## Cbrine (May 30, 2008)

I'm in agreement somewhat...something more along the lines of the vba .offset() method would be more efficient.  Just define the lookup data, and tell it to offset from where it finds the match...and as was stated above, let negative values be used.  This would limit the array size and still let you lookup multiple column values.  I've had cases where I'm looking up more than one column from the same vlookup table, and I don't want to have to define multiple tables to get the data.


----------



## Oorang (May 30, 2008)

DreamAlchemist said:


> Perhaps I am not understanding what you are asking, but I find the Vlookup to be fine.


It does work fine. The point I am making is that the because the lookup column is always the leftmost column of the lookup table. And you can only return the value from one column, the lookup table you specify (barring sloppiness) is never going to be wider then lookup column to return column. So it should be a give that the return column number is the number of the rightmost column. There is no need for that parameter. Instead of =VLOOKUP(A1,B2:C24,2,0)  It should just be =VLOOKUP(A1,B2:C24,0) and it's a given the return column is C.


----------



## Oorang (May 30, 2008)

Because it's me I couldn't resist making my own  It could be optimized for speed, but this is something that functions the way I was thinking. But to be honest I tend to steer clear of UDFs because people either won't have the add-in you make, or have macro's enabled etc.


```
'-------------------------------------------------------------------------------
' Module       : UserDefinedFunctions
' Author       : Aaron Bush
' Date         : 05/30/2008
' Purpose      : Contains Functions intended to be available to user in
'                Microsoft Excel.
' References   : Visual Basic For Applications
'                C:\Program Files\Common Files\Microsoft Shared\VBA\VBA6\
'                VBE6.DLL
'                Microsoft Excel 11.0 Object Library
'                C:\Program Files\Microsoft Office\OFFICE11\EXCEL.EXE
' Dependancies : None
'-------------------------------------------------------------------------------
Option Explicit
Option Compare Binary
Option Base 0
'Option Public Module

'Setting this to True will turn off all error handling:
#Const m_blnErrorHandlersOff_c = False


Public Function SVLOOKUP(ByVal value As String, ByVal lookupTable As _
    Excel.Range, Optional ByVal matchCase As Boolean = False) As Variant

    '---------------------------------------------------------------------------
    ' Procedure : SLOOKUP
    ' Author    : Aaron Bush
    ' Date      : 05/30/2008
    ' Purpose   : Simple Lookup. Provides a simpler VLOOKUP syntax by assuming
    '             the return column is the left column in the range and an
    '             replaces the esoteric Range Lookup paramter with an
    '             optional Case-Sensitivity paramter.
    ' Input(s)  : value       - The value to be looked up.
    '             lookupTable - The table that contains the data you want a
    '                           lookup performed on.
    '             matchCase   - Optional. Determines case-sensitivity. Default
    '                           is false.
    ' Output(s) : If value is encountered in the left-most column of the lookup
    '             table, the return value will be the value of the same row,
    '             but the rightmost column of the lookup table. The first value
    '             encountered is used.
    ' Remarks   : Variant return type used to accomdate excel numbers and
    '             strings.
    ' Revisions :
    '---------------------------------------------------------------------------

    Const strNotFnd_c As String = "#NotFound!"
    Const lngLkupClmn_c As Long = 1
    Dim wsParnt As Excel.Worksheet
    Dim rngLkup As Excel.Range
    Dim cll As Excel.Range
    Dim varRtnVal As Variant

    'Conditionally Invoke Error Handler:
#If Not m_blnErrorHandlersOff_c Then
    On Error GoTo Err_Hnd
#End If
    Set wsParnt = lookupTable.Parent
    Set rngLkup = Excel.Intersect(lookupTable.Columns(lngLkupClmn_c), _
        wsParnt.UsedRange)
    If matchCase Then
        For Each cll In rngLkup.Cells
            If cll.value = value Then
                varRtnVal = wsParnt.Cells(cll.Row, lookupTable.Column + _
                    lookupTable.Columns.Count - lngLkupClmn_c).value
                Exit For
            End If
        Next
    Else
        value = LCase$(value)
        For Each cll In rngLkup.Cells
            If LCase$(cll.value) = value Then
                varRtnVal = wsParnt.Cells(cll.Row, lookupTable.Column + _
                    lookupTable.Columns.Count - lngLkupClmn_c).value
                Exit For
            End If
        Next
    End If
    If cll Is Nothing Then
        varRtnVal = strNotFnd_c
    End If
    '******* Exit Procedure *******
Exit_Proc:
    'Supress Error Handling to Prevent Error-Loops:
    On Error Resume Next
    'Release Objects:
    Set wsParnt = Nothing
    Set rngLkup = Nothing
    'Set Return Value:
    SVLOOKUP = varRtnVal
    Exit Function
    '******* Error Handler *******
Err_Hnd:
    varRtnVal = Err.Description
    Resume Exit_Proc
End Function
```


----------



## SydneyGeek (May 30, 2008)

Yes, VLookup is expensive, but only if you let yourself be conned. 

Wide tables definitely make VLookup expensive -- so do very tall ones. A few years ago I built a spreadsheet that used nested VLookups on two large tables. The workbook was unusable -- about 10 minutes to refresh after each edit. Restricting the VLookups so they only looked above the current row (the data was chronological) made a huge difference, along the lines of the Column() comment above. 
If I'd though harder about it, Index / Match would have been much better. 

Denis


----------



## mortgageman (May 31, 2008)

Oorang said:


> It does work fine. The point I am making is that the because the lookup column is always the leftmost column of the lookup table. And you can only return the value from one column, the lookup table you specify (barring sloppiness) is never going to be wider then lookup column to return column. So it should be a give that the return column number is the number of the rightmost column. There is no need for that parameter. Instead of =VLOOKUP(A1,B2:C24,2,0) It should just be =VLOOKUP(A1,B2:C24,0) and it's a given the return column is C.


 
While I agree that vlookup is zoolander flawed in that it can't look to the left (and here is a udf I wrote sometime ago to address it:

http://www.mrexcel.com/forum/showthread.php?t=154622&highlight=vlookup )

Surely, if the table is more than two columns wide then the column number is needed?  Or did I miss something?


----------



## schielrn (May 31, 2008)

This is what I came up with for positives or negatives, but it could definitely be cleaned upo:


```
Function vlook(lookupValue As Variant, lookupRange As Range, columnNumber As Integer, Optional trueFalse As Boolean)
    On Error GoTo handler
    If columnNumber > 0 Then
        vlook = Application.WorksheetFunction.VLookup(lookupValue, lookupRange, columnNumber, trueFalse)
    ElseIf columnNumber < 0 Then
        vlook = Application.WorksheetFunction.Index(Range(Mid(lookupRange.Address, InStr(1, lookupRange.Address, ":") + 1, 10) & ":" & Mid(lookupRange.Address, InStr(1, lookupRange.Address, ":") + 1, 10)).Offset(, columnNumber + 1), Application.WorksheetFunction.Match(lookupValue, Range(Mid(lookupRange.Address, InStr(1, lookupRange.Address, ":") + 1, 10) & ":" & Mid(lookupRange.Address, InStr(1, lookupRange.Address, ":") + 1, 10)), 0))
    Else
        Exit Function
    End If
    Exit Function
handler:
    vlook = Evaluate("=na()")
End Function
```
It uses the vlookup function and index/match, but thats ok it made the code a little shorter in my opinion.  You can still use a bigger table than is expected like with the original formula.  So you can input:

=vlook(B2,E:H,4,0)
=vlook(B2,H:E,-4,0)
=vlook(B2,H:A,-4,0)


----------



## Oorang (Jun 1, 2008)

mortgageman said:


> Surely, if the table is more than two columns wide then the column number is needed?  Or did I miss something?



A lookup table never needs to be any wider than the lookup column to the return column. As VLOOKUP assumes the lookup column is always leftmost, it should also assume the return column rightmost.


----------



## PaddyD (Jun 1, 2008)

"A lookup table never _needs _to be any wider than the lookup column to the return column."

Indeed not, although I see no reason not to think that it's useful to be be able to write this sort of thing:

=vlookup(a1,lookup_table,(column()-1)*2,0)

...whereby incrementation of the (column()-1)*2 argument allows you to return alternate column results from a wide table-array without further changes to the formula.  In my view, useful enough to warrant the need to specify which column you're after.


----------



## Lewiy (Jun 2, 2008)

Personally, I think that’s it’s very useful having the column indicator there.  If I want to return several items from a table that are not consecutive, I can write one formula that I can copy across.  For example, if I want to pull data from every other column in the table, I’d use something like:
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-comfficeffice" /><o> </o>
=VLOOKUP("value",$A:$G,COLUMN(A1)*2,0)
<o> </o>
This would be much harder to achieve if the column argument was not there.
<o> </o>
Also, as previously mentioned, using named ranges makes this an important argument.


----------



## litrelord (Jun 2, 2008)

I have to disagree as well. I use vlookup combines with column a lot for transferring data from one table to another. It may be expensive but as a quick and easy way to combine tables I find it invaluable. 

Although the not looking to the left is extremely irritating at times. Although I know I can use a UDF or a combination of index & match I quite often just end up making a copy of the column I'm searching for and delete it again afterwards. 

I'm all for formulas and code that's as efficient as possible but only when creating a model in excel which will be re-used. For an ad-hoc report it's whatever gets the job done quickest. 

Nick


----------



## Lewiy (Jun 2, 2008)

litrelord said:


> I'm all for formulas and code that's as efficient as possible but only when creating a model in excel which will be re-used. For an ad-hoc report it's whatever gets the job done quickest.


 

I completely agree.  Clearly it’s more important to streamline applications and re-usable macros, especially of they are dealing with a lot of data, but if you are just chucking numbers around to create something off the cuff, then it doesn’t really matter how expensive your formulas are (unless you make the mistake I did of using SUMPRODUCT for five columns on 30,000 rows – that’s 450,000 formulas for those who are counting – this took so long to calculate that I gave up in the end!).


----------



## cornflakegirl (Jun 2, 2008)

Paddy, Lewiy - thanks for the alternate column tip!

Can I ask - why is Index/Match better than Vlookup? I'd always assumed that Vlookup worked in the same way as if I constructed an Index/Match, and was just saving me a bit of typing...


----------



## Domski (Jun 2, 2008)

> why is Index/Match better than Vlookup?


 
To my mind I use VLOOKUP when I just want to return one column of data.

If, for example, I was going to return a number of columns from the same data table then using Index and Match is more efficient if you use the Match formula in a helper column to find the relative positions of the data to return and then a bunch of Index formula based on that.

It's more efficient that way as it's only doing the lookup part once rather than multiple Vlookups having to go through the process of locating the correct data in each individual formula. When you dealing with thousands of records the performance difference is very noticeable.

Dom


----------



## cornflakegirl (Jun 2, 2008)

Thanks Dom.


----------



## Richard Schollar (Jun 2, 2008)

I use INDEX/MATCH when the lookup column is on the right-hand side of the column containing the value I wish to return.


----------



## Greg Truby (Jun 2, 2008)

OK - since ain't nobody up an' said it, I will.  Like Richard I'll use VLookup() when fetching ta the right and Index(Match()) when fetchin' left.  What I won't do, is to pop in a UDF - in spite of the ease of writing one.  Mainly because of the VBA security crapola.  Yes, I could digitally sign the workbook.  Yes, I could have the user install my digi-sig if he ain't got it (assuming, of course, that his security is set to medium and not high or VH).  Or, I could put the code in a custom add-in, that would at least make it more "accessible" to the workbook.  But then I'd have to distribute the add-in.  And all of this to avoid using Index(Match())?  Blech! 

Now I'll get off'n the soapbox and just nod my head in that yes, I too cannot figure out why the fellers that wrote it didn't let 'er look ta the right 'n' fetch from the left too.  

The other burr under my saddle is having ta specify the entire range yer lookin' into.  More'n once I've gotten a blasted #REF! error 'cause I want a column that's off the right end of my "table_array" and I gotta go back and widen 'er up a bit.  A while back I figured out that this "pass in the whole table" bit would be necessary for the function to process "hard-coded" arrays, in addition to ranges.  But I woulda hoped the fellers that wrote the function coulda made 'er smart enough to have it behave differently based on the type of input received.  ['course considerin' the thing don't even "fetch left", I reckon I ought not to be surprised. ]


----------



## Domski (Jun 2, 2008)

Match does have the advantage of having the 3 match options (nearest lower, exact or nearest higher) which Vlookup doesn't. Another ommission in my opinion.

Dom


----------



## Oorang (Jun 2, 2008)

PaddyD said:


> Indeed not, although I see no reason not to think that it's useful to be be able to write this sort of thing:
> 
> =vlookup(a1,lookup_table,(column()-1)*2,0)
> 
> ...whereby incrementation of the (column()-1)*2 argument allows you to return alternate column results from a wide table-array without further changes to the formula.  In my view, useful enough to warrant the need to specify which column you're after.



Yes but you could still have that functionality by changing the table reference instead of the column:

=SVLOOKUP(A1,INDIRECT("Sheet2!$A$1:"&ADDRESS(50,((COLUMN()-1)*2))))


But that, said some people have a few good arguments about why it should stay. I think I like the suggestion that it just be optional and default to rightmost column, then you could have your cake and eat it too.


----------



## Jonmo1 (Jun 2, 2008)

Another very useful reason to have the colref in vlookup that I don't think has been touched on...So it can vary dependant upon user entry...

Say you have a vlookup of a part number, and Columns for Price/Color/Weight/Bin Location/whatever...

you can make your Colref Variable depending on a user entry in another cell, if they want to view the different properties of the part number.


Again, this is still better obtained with Index/Match, but the discussion is about Vlookup....


----------



## Oorang (Jun 2, 2008)

That's a pretty compelling argument. You could then link the to a combobox index, etc then they could just select the column of the combo box and the formula would pull the data.... But wait... You could STILL do that by just changing the table reference dynamically instead of the column number! 


Although to be fair, a dynamic table reference is conceptually less accessible to a new user so it would steepen the learning curve.


----------



## Jonmo1 (Jun 2, 2008)

Maybe our argument should be...

Why do we need Vlookup at all ?


----------



## schielrn (Jun 2, 2008)

> Why do we need Vlookup at all ?


 
That would be a very good argument as many have said that they use index/match instead of vlookup for many of different reasons.  But with beginners I find it much easier to teach them vlookup as opposed to using Index and Match.


----------



## Jonmo1 (Jun 2, 2008)

> But with beginners I find it much easier to teach them vlookup as opposed to using Index and Match


 
And there is the answer to the Question in the OP.

I still say the best way to please everone would be to make the ColRef Optional, and default to the rightmost column.  But I'm not a developer at Microsoft....


----------



## Oaktree (Jun 2, 2008)

mortgageman said:


> While I agree that vlookup is zoolander flawed in that it can't look to the left ...



Am I the only one who gets that reference?!?  VLOOKUP is not an ambiturner!

Remember that not every Excel user lives and breathes the stuff like us.  Many of them are the =SUM(A1+A2) type.  For casual users, having an easy way to get a result is well worth a few milliseconds of efficiency.  VLOOKUP might take some time to learn, but Mr. T pities the fool who tries to explain dynamic arrays and INDEX/MATCH to a =SUM(A1+A2) loyalist.

As another example, sometimes it's just easier to tell someone to use ISEVEN than it is to explain the concept of modulus.


----------



## Jonmo1 (Jun 2, 2008)

> Am I the only one who gets that reference?!? VLOOKUP is not an ambiturner!


 
Not anymore, I get it now...

ROTFLMAO !!!!!


----------



## Jonmo1 (Jun 2, 2008)

You know the exact same argument can be made for Hlookup. Just like Vlookup can't read left, Hlookup can't read up (event though it's called Hlook*up *)

In fact, I'd bet (not the house or anything) that half of the people who do use Vlookup, probably use Index/Match instead of Hlookup...


----------



## NateO (Jun 2, 2008)

Oaktree said:


> ... a =SUM(A1+A2) loyalist.


That's great!


----------



## Greg Truby (Jun 2, 2008)

Oaktree said:


> ...Many of them are the =SUM(A1+A2) type...


 Only ever saw that done once. She's been promoted four times in eight years.


----------



## PaddyD (Jun 2, 2008)

while I think of it, another useful consequence of being able to specify the column argument:

=vlookup(a1,table_array,{2,3,5,7},0)

...array-entered into a 1*4 range


----------



## Oorang (Jun 2, 2008)

Oaktree said:


> Am I the only one who gets that reference?!?  VLOOKUP is not an ambiturner!


Hahahaha! I didn't make the ambiturner connection I was just thinking "as stupid as zoolander". Should have expected more from MM 



			
				Oaktree said:
			
		

> ... a =SUM(A1+A2) loyalist.


If have trained so many people in VLOOKUP it's not funny, and I have yet to get someone to _really_ understand it without drawing them a picture. Now it's like "Will you show me how to use VLOOKUP?" and I just automatically have them get a paper and pen.


----------



## Oorang (Jun 2, 2008)

I even give them a little fill in the blank sentence: 
Me: "Lookup _blank_ in table _blank_. And if you find it, give me column _blank_ from the row you found it in." 
Them: "What is that last box for?"
Me: "For now it's always zero."

Of course you still have to spend time explaining the difference between a table and a worksheet, that #N/A! doesn't mean you did anything wrong, and that numeric 1 is not the same as text "1". Oh and 0 means you found a blank cell.


----------



## Lewiy (Jun 3, 2008)

I find my biggest problem is explaining to people that they need to make sure they don’t have any preceding or trailing blanks in their data, otherwise VLOOKUP will not work (or INDEX/MATCH for that matter).  They seem to not realise the importance of accurate data entry and assume that things will “just work”.  When they don’t work, they decide immediately that “complicated formulas” are not worth the effort and spend hours doing things manually instead!!
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-comfficeffice" /><o> </o>
While we’re on the subject, here’s a classic quote from a colleague earlier this week:
“If I sit with you for five minutes, can you please show me how to all the things you do in Excel?  I can do formulas like SUM and even AVERAGE so I’m well on my way…………..what’s a macro?”


----------



## litrelord (Jun 3, 2008)

Lewiy said:


> “If I sit with you for five minutes, can you please show me how to all the things you do in Excel? I can do formulas like SUM and even AVERAGE so I’m well on my way…………..what’s a macro?”



Know that feeling. Before changing departments my previous supervisor asked me to write up an explanation of the macros they still used with 'detailed instructions showing how to update them is necessary'. I told them if I could do that I'd be publishing Excel help books not working here. 

(VLOOKUPs are very useful - just thought I'd mention them in case I get accused of an off-topic post)

Nick


----------



## mortgageman (Jun 3, 2008)

Oorang said:


> Hahahaha! I didn't make the ambiturner connection I was just thinking "as stupid as zoolander". Should have expected more from MM


 
That's me - I troll these boards making sure that all cultural references  are at a (G-d help us) elevated level.


----------



## Cbrine (Jun 3, 2008)

One things I don't think anyone has mentioned, is an issue I encountered a few times.  Mostly my own fault using Index(Match()).  I've had occasions where I've misaligned the ranges in the index(Match()) and ended up with results that looked OK, but were totally wrong.  I realize a little validation on my part would have found the problem, but this is not something that can happen with a vlookup, since it's only a single range.


----------



## HalfAce (Sep 18, 2008)

> “If I sit with you for five minutes, can you please show me how to all the things you do in Excel? I can do formulas like SUM and even AVERAGE so I’m well on my way…………..what’s a macro?”


Yeah, similarly, one of my favorite questions is:
"Hey, can you teach me Excel?". . .


----------



## RoryA (Sep 18, 2008)

I would have been happy with:
=VLOOKUP(lookup_value,lookup_column_range,return_column_range,match_type)
possibly with an optional 5th argument of what to return if no match.


----------



## gingerafro (Sep 19, 2008)

I'll firstly admit that I don't understand exactly how formulas work and therefore what performance issues there are, but what would be the arguments against the formula which on the face of it appears simpler than INDEX/MATCH:

=SUMPRODUCT(--($B$1:$B$10000=E1),($A$1:$A$10000))

to do a 'left lookup' on values entered in the E column.


----------



## RoryA (Sep 19, 2008)

That would require the return value to be a number and for there to only be one match. You also wouldn't be able to use the equivalent of the TRUE argument in VLOOKUP.


----------



## gingerafro (Sep 19, 2008)

I get that, thanks.
Most of my Vlookups are to return a value for an exact match in a list of unique items, which is why I hadn't considered those pitfalls.
I did try my example using a long list and the performance is terrible.  So the answer is in theory it does work, but only in certain situations and for small ranges.

Therfore is no substitute for INDEX/MATCH.  I was just trying to find an easier way to write a 'Left Lookup' that my colleagues who are infrequent excel users could copy.


----------



## schielrn (Sep 19, 2008)

Ok that got me thinking maybe you could use lookup to look left if you know there is always going to be an exact match and unique values, but it did something wierd when there are not unique values?  Can anyone possibly explain why this happened?Book1ABCDE12345rt567eddir5eddir8rob9101112rob5Sheet1
E7 and E8 are both looking up 5 within B1:B12 and returning the value from A1:A12.  Now one uses a whole column reference and returns the last value found.  And the one that uses the exact range returns the 2nd value found?  And if I add another 5 and name in A9:B9 the full column reference the 3rd one is returned and not the last one anymore?Book1ABCDE12345rt567eddir5eddir8steve9steve5101112rob5Sheet1
Now I don't use lookup all that oftern, so I don't necessarily completely understand it, but I cannot figure out a patter on how it is actually looking these up?  I know the range normally has to be sorted for it to work properly, but I am not using different values.  Can anyone kindly explain this to me?

Thanks.


----------



## cornflakegirl (Sep 19, 2008)

You're not using different values, but you do have blank cells. If you put values in the other cells, it will pull back the last one.

(It is odd though!)


----------



## Deano (Sep 22, 2008)

Interesting one.

If you get a little creative with the OFFSET function, you can combine it with the vlookup value to decide if you really want VLOOKUP to start at the first column of your table.  The same can be applied to the column number as this could also be variable.

Regards


----------



## Angelicus (Sep 22, 2008)

Lewiy said:


> While we’re on the subject, here’s a classic quote from a colleague earlier this week:
> “If I sit with you for five minutes, can you please show me how to all the things you do in Excel?  I can do formulas like SUM and even AVERAGE so I’m well on my way…………..what’s a macro?”



If this quote is not good enough I heard another one from a staff working in an embassy. When she applied for courses in Excel, her colleague replied. "Even my 8 years old daughter knows everything about Excel already!"

Well, I cannot instantly doubt this possibility


----------

