Just did a reading of the webpage I posted the link to. Clearly it has
been updated to include much more since I last read it some years back.
I see your point now with respect to a table [object], where I was
first thinking you meant a defined area (n rows by n cols) that was
named.

As for workbook overhead, my understanding/experience with table
objects is that they are (or can easily be) overhead intensive! Most of
my work with data sets involves 'in memory' processing either via ADODB
or VBA arrays. I normally use worksheets as database tables to display
content stored in plain text files. (The files may or may not be
encrypted)

Where data needs to be manipulated via criteria at runtime, I find a
multi-column listbox in a userform the easiest (low overhead) approach.
Because individual fields can't be selected I use a combobox control to
dynamically update when a record is selected so users can access the
individual fields. I find most users like this as opposed to using the
built-in dataform, because they like to see the data laid out in a
grid-like display. Optionally, I do have the fpSread.ocx ( a 3rd party
ActiveX spreadsheet) which works well as a data control also (one of
several other advantageous features).

Thus, my work with pivot/named tables is fairly minimal, but most of my
clients complain about how slow named tables are. Makes sense, though,
given the number of properties/methods attached! Defined ares don't
have that overhead...<g

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion



---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com