Actually, the worksheets I'm planning on copying from a centralized file
(where all of the data are gathered and processed) are the ones involving
charts. Rather than using arrays as arrays are kinda a generic form with
restrictions and can also be inefficient for certain cases, I been using
class modules, enumerations, and collections instead.

Some might as why not use "Types". Well with the onset of VB.NET, Types are
not allowed and if there comes a time when the code needs to be transferred
to a VB.NET environment, like to spend as little time converting as
possible. That's just one of the restricts to the .NET environment as
compared to VB6 programming environment that MS Office 2000 - MS Office 2003
(can't speak for MS Office 2007) uses a subset of for it's VBA programming
environment.

As for defined names, I would still be dependent on defined names for range
references within VBA as data from our main database is brought into Excel
on worksheets via a 3rd party program, which then VBA takes over from there
to manipulate the data and put into report format. There are many things
that I have done via SQL first, but just as there are restrictions and
limitations to VBA, there's also restrictions and limitations to using SQL
as SQL can't do certain things.

These are codes that's ran nightly and completed before I even come into
work in the morning.

--
Thanks,

Ronald R. Dodge, Jr.
Production Statistician
Master MOUS 2000
"Mike H." wrote in message
...
Why not build an array that contains all the data from the source sheet
and
then go to the destination, insert a new sheet and populate all the cells
based on the array. Not sure how big an array can actually be, but if you
bumped into a problem, you could break your "copying" into segments, read
part, populate part, read more, populate more, etc. Then you'd get no
names.