I would suspect you need to pursue what you know best.

--
Regards,
Tom Ogilvy


"(PeteCresswell)" wrote:

Per (PeteCresswell):
some Excel-specific
syntax to avoid beating down the table looking for a match.
--

I've got vLookup working.... sort of....

Did the concatenate column values thing in the table and am then
concatting the two cells' .Values on-the-fly into an invisible
cell and basing the vLookup on that cell containing the
on-the-fly concatenated names.

Right now it's not working with the range parm = False... i.e. it
will do a fuzzy match but fails on an exact match.

Before I spend any more man hours trying to get around that, I
would pose the following question:
----------------------------------------------------------------
Given that we will be doing maybe 20-30 vLookups (one for each
cell that has tb populated) each time the user changes one of the
key cells, will that start to slow things down unduly when we get
a thousand or so rows in the table tb searched? Right now we
only have a couple hundred.

I'm thinking that maybe I should fall back to my kneejerk
solution, which was to case out on Target.Row/Target.Column and,
if it's the second key cell, just concat my key values in VBA,
set a .Range to the lookup table, and beat down the first column
of the .Range looking for a match. Then, once a match was
found, iterate across the table's row populating columns in the
sheet the user sees.

Seems to have the advantages of being up-front (i.e. you look at
the VBA code, and you see the whole picture..), being
more-or-less of a sure thing, and only requiring a single
(instead of 20-30) trip through the table looking for a
match..... and I'm guessing that with a little effort, I could
make the table search binary.
----------------------------------------------------------------

Any thoughts on this?
--
PeteCresswell