I'm back online, so I'll rejoin the discussion :-).

What you are doing looks workable (right or correct is subjective, so I
won't comment on that :-)). Just one point to pick up on though that you
mentioned. You said '... You must have read my mind, though, because there
*will* be occasions to expand the number of rows, which is why I want to use
rows.count rather than a specific number of rows ...'. Your approach does
not protect you against that. For example, say 'Name_Copy' refers to a range
A1:M20, then rows.count returns 20, and your variable will have 20 as its
value. However, say a new row gets inserted at row 10, then 'Name_Copy' will
then refer to A1:M21, but your variable will still have the value 20 in it.
QED - a problem. That is why it is sometimes better to recalculate such
values just prior to using them. Public variables can be good, but you still
need to know what is going on to use successfully.

--
HTH

Bob Phillips

"David" wrote in message
...
?B?V2FsdA==?= wrote

It might be useful to look in the help
system of your Visual Basic Editor for the subjects "Declaring
Variables" and "Understanding the Lifetime of Variables". These will
give you some insight to the different types of varables, from where
and how their values can be accessed, and the duration of their value
retention.

Oops, I was looking in Excel Help, not VB Help.

--
David