Welcome to MSDN Blogs Sign in | Join | Help

Tables Part 1: Working With Tables Of Data

For the next few posts, I’d like to spend some time explaining the work we’ve done in Excel 12 to improve the experience of working with tabular data in Excel.

One thing that we see pretty much every Excel user doing with some frequency is working with tables.  Tables can mean different things to different people so let me briefly define what we think of when we use the word table.  A table is a simple structure where each row corresponds to a single “thing” (e.g. a specific transaction, an individual product, etc.), and each column denotes a specific piece of information that’s shared by all rows (e.g. amount of each transaction, product quantity, etc.).  Tables typically have a “header” row at the top that defines the information that each column contains. Some examples of tables might be a list of financial transactions or the latest inventory numbers pulled from a server.  Here’s an example of a very simple (and fictitious) table.


(Click to enlarge)

The two-dimensional nature of the spreadsheet makes it an obvious canvas for manipulating and analyzing tabular data.  Excel, however, has traditionally offered very little in the way of features aimed at tabular data because it had no built-in knowledge of what a table is or how it should behave.  We’ve done a lot of work to make tables a native structure in Excel 12.  When Excel knows you are working with a tabular structure, it can react much more intelligently to the actions you perform in the grid.  Let me demonstrate by way of a simple example.  Here is what our table might look like if we formatted the table, applied a data bar to the Profit column, added a chart, and added a formula at the top of the sheet that totals the Profit column.


(Click to enlarge)

The next thing I might typically do is add some more data.  Let’s look at what happens when I type a value just below the table in cell D9.


(Click to enlarge)

After I pressed Enter, several things happened for me automatically:

  1. The value that I entered was consumed into the table.  Excel assumed I was appending data to my table (if I wasn’t, one click will tell Excel to not auto-expand the table)
  2. When the table consumed the data, my table formatting automatically extended to the new row – and notice that it was smart enough to maintain my alternating row colors
  3. The conditional formatting data bar also extended to the new row, so Excel is now using D5:D9 to calculate the relative size of the data bars 
  4. The formula at the top updated itself to include the new data
  5. Finally, the chart updated as well to reflect the addition to our table

Without a table, I would have to manually adjust the cell formatting, conditional formatting, formula and chart every time I append a value.  What would have taken half a dozen steps or more now happens for me automatically thanks to the table feature.  This is because Excel now recognizes features like a table, table columns, table header and so forth, and can use that knowledge to make informed decisions about what to do while I’m working in the spreadsheet.  The best part is that I am just scratching the surface here; it will take me several posts to fully explain the benefits of tables and all the new features surrounding it.  For now let’s cover some basics.

Creating Tables

A table can be created simply by clicking on the Table command on the Insert tab in the ribbon (even quicker, use the CTRL+L shortcut key).  Clicking the Table command brings up a dialog box where you specify the range for your table, and indicate if your data already contains a header row.


(Click to enlarge)

When you create a table, a new tab appears on the ribbon that is specifically designed for tables.  The tab only appears when the active cell is inside a table.  The tab contains options and settings that are geared for tables.  I won’t go into the details right now, but here’s a screenshot.


(Click to enlarge)

Another bit of work that we did was to merge our table feature with the existing external data query functionality, sometimes referred to as query table.  New queries will therefore also benefit from the features of tables (at the moment, web queries and text queries are excluded from this).  I think the benefit of making query tables into tables will become clear over the next week or two as I go over the capabilities of Excel 12 tables.  Note, if you have an existing query, you can convert it to a table using the Ribbon or keyboard shortcuts described above.  Tables are also created when you import XML data using the XML features we added in Excel 2003.

Entering Data into a Table

We already saw in the example above how to add a new row to a table.  Adding a new column works the exact same way.  Place the active cell just outside the table to the right, enter a value and Excel will automatically grow the table to consume the data that you entered.  If this isn’t the desired result, then a simple command will shrink the table back and leave the value outside the table.  This “auto-expand” behavior can also be turned off.

There are a couple other ways to add rows.  Much like tables in Word, pressing TAB when the active cell is in the last column of the last row will cause Excel to add a new row and move the active cell to the first column of the newly added row.  In addition, pressing ENTER when the active cell is in any cell of the last row will also cause a new row to be added.

Finally, if you want a quick way to resize your table to add or subtract rows or columns, click the resize handle in the lower-right corner of the table and drag it in the direction desired.  You can spot the resize handle in the screen shots above.

One of the goals of the table feature is to maintain the integrity of your tabular structure, so the only way to shift cells or create space in a table is to add or insert entire table rows or entire table columns. 

By the way, some of this may look familiar if you’ve ever used the list feature in Excel 2003.  The table feature is in fact based off lists, but as you’ll see over the next few days we’ve built a much more comprehensive feature set around tables.

Over the next few days I plan to show you:

  • More of the core features of tables
  • The great things that happen when tables and formulas collide
  • Filtering table data & AutoFilter improvements
  • Table Styles and smart formatting behaviors
Published Tuesday, October 25, 2005 3:56 PM by David Gainer
Filed under:

Comments

# re: Tables Part 1: Working With Tables Of Data

Tuesday, October 25, 2005 7:52 PM by Graham
Hi David,

Looks nice, seems intuitive.

A detail: how does the alt row shading work alonside conditional formatting? Does the latter override the former, or is the alt row shading done via CF?

Thanks

# re: Tables Part 1: Working With Tables Of Data

Tuesday, October 25, 2005 8:01 PM by David Gainer
Hi Graham - Conditional Formatting will override the row shading (or "Table Style" formatting). It isn't easy to see in my example, but that's the design. "Table Styles" are a lot more than alternating row shading - I will cover that in detail in a few posts.

# re: Tables Part 1: Working With Tables Of Data

Tuesday, October 25, 2005 9:44 PM by Harlan Grove
Boldy adding functionality Lotus 123 provided 6 years ago! Whoda thunk!

Some of this is useful, but some of the rest will be yet more intrusive automatic functionality to be disabled as soon as possible. It will be possible to disable most of this, won't it?

As for the automatic properties you mentioned, just add a line at the bottom of a range containing either ="" or ' in each cell and with number format ;;;"_________", and always insert rows beginning with this row. This already provides the functionality you describe. All you've done is added this to autoenlarging ranges, er, tables.

How does this interact with worksheet protection?

Will tables be accessible as ranges, or will it be necessary to convert them to ranges to access them in formula? I guess I'm anticipating a subsequent post.

# re: Tables Part 1: Working With Tables Of Data

Tuesday, October 25, 2005 11:27 PM by Jon Peltier
"By the way, some of this may look familiar if you’ve ever used the list feature in Excel 2003."

For me, this was sufficient reason to upgrade for my own use (many clients are still stuck in 2000, so I use that one too). Looks like they're on steroids in 12.

# re: Tables Part 1: Working With Tables Of Data

Tuesday, October 25, 2005 11:53 PM by David Gainer
Hi Harlan - Bear with me over the next week or so while I get through some more details on our work in this area – I think you will see how the work we are doing is pretty fundamental and provides a better solution in most cases than auto-enlarging ranges. Just based on the stuff I covered today, for example, smartly maintaining formatting like banding isn’t possible with that approach, charts don’t update when you add data, references to the table don’t update, etc.

One thing to note is that we do not auto-guess tables. Users have to explicitly declare something a table (like in Word or PPT), and once they do, they get the functionality offered by Excel 12. If a user doesn’t want that functionality and wants to work with auto-enlarging ranges, they simply don’t declare the range a table.

Additionally, if a user has made something a table, they can absolutely turn off the auto-expand of rows and columns (though I believe that in most cases users will want auto-expand, since it seems to be proving quite intuitive and since it fixes up things like the formatting, borders around the table, and a whole host of other stuff). In addition, every time we auto-add a row or column, we will provide UI (like the UI that comes up when you paste a range that lets you adjust the formatting) that allows you to undo the expansion. Our design principle is that the user has to be in full control at all times, and that the user has to be able to undo any “auto” action with no more than one or two clicks.

WRT protection, stay tuned for my next post.

Jon – much more to come!

# re: Tables Part 1: Working With Tables Of Data

Wednesday, October 26, 2005 1:19 AM by Harlan Grove
David Gainer...
...
|Just based on the stuff I covered today, for
|example, smartly maintaining formatting like
|banding isn’t possible with that approach,
|charts don’t update when you add data,
|references to the table don’t update, etc.
...

Reread my setup. If banding is provided by conditional formatting formulas, e.g.,

=MOD(ROW(),2)

and there's an bottom row with empty cell contents but visible text, inserting rows at that bottom row DOES extend banding to inserted rows, DOES extend number formatting (all formatting), and DOES expand chart ranges that include the contents-empty but visually-nonempty bottom row. Would you like a sample workbook to show how it works?

| . . . (though I believe that in most cases
|users will want auto-expand, since it seems to
|be proving quite intuitive and since it fixes
|up things like the formatting, borders around
|the table, and a whole host of other stuff).

OK, I may just be different. Realize that I've worked with query tables in Lotus 123, which work very much as you describe Excel tables. I found them to be more trouble than they were worth, but that's just my experience.

|In addition, every time we auto-add a row or
|column, we will provide UI (like the UI that
|comes up when you paste a range that lets you
|adjust the formatting) that allows you to undo
|the expansion. Our design principle is that
|the user has to be in full control at all
|times, and that the user has to be able to
|undo any “auto” action with no more than one
|or two clicks.
...

Oh good. So you're going to extend this exemplary principle to importing CSV files, in which versions through XL11 *IGNORE* quoting of fields containing text that could be interpreted as numbers, making it essentially impossible to import CSV files containing, e.g., US Zip Codes with leading zeros as separate fields. For example, the following one-line CSV file

"XYZ Inc","123 Gizmo Way","Nashua","NH","06350"

which XL11 & prior will fubar the zip code as (numeric) 6530. Will XL12 empower the user with regard to CSV files? Will someone on your team FINALLY include a optional setting to run the text import wizard for files with .CSV extensions the same as it does for files with .TXT or .PRN extensions? Or maybe just do the decent thing like 123's classic /FIN command, and read *EVERY* double-quote delimited field as **TEXT**!

Consistency in implementing your claimed design philosophy would be nice, "the user has to be in full control at all times." Or is that the user gets to have the illusion of control only here & there?

# Know your Excel

Wednesday, October 26, 2005 1:42 AM by SlashDotJunkie
Harlan Grove: "Oh good. So you're going to extend this exemplary principle to importing CSV files, in which versions through XL11 *IGNORE* quoting of fields containing text that could be interpreted as numbers, making it essentially impossible to import CSV files containing, e.g., US Zip Codes with leading zeros as separate fields."

Rename .csv to .txt, open, choose comma as separator, mark column with zip codes as text. How hard is that?

# re: Tables Part 1: Working With Tables Of Data

Wednesday, October 26, 2005 4:09 AM by Paul Morriss
SlashDotJunkie:
Not hard, just fiddly. Why can't Excel pay attention to the quotes?

# re: Tables Part 1: Working With Tables Of Data

Wednesday, October 26, 2005 4:23 AM by anon

I find it funny that no one mentions that the *new* Table thing is Office 2003's lists.

# re: Tables Part 1: Working With Tables Of Data

Wednesday, October 26, 2005 4:25 AM by Nigel Harper
Dave,

I think the changes you have made are tremendous and I have no doubt that I will continue to think so as you reveal more of Excel 12. I'm not sure how long you have been Group Program Manager for Excel but the whole product seems to have taken a giant leap forward under your care - well done to you and your team. With a product like this nothing is ever finished or perfect, not even to any one person's own satisfaction, and there are always going to be competitor's products who have slightly different (or even better?) ways of doing things, but that is simply the nature of the beast.
I say all of this because I am growing slightly tired of Harlan Grove's continuing sarcasm. Clearly he is an Excel expert and knows his beans and so I try to read his comments with interest. However, I am finding his scoffing tone rather tedious and a little unfair and would prefer it if he could be a little more objective in his questions and observations.

Thank you,
Nigel


# re: Tables Part 1: Working With Tables Of Data

Wednesday, October 26, 2005 4:32 AM by anon

Oops, sorry, the lists from which tables are based are mentioned in the original post.

# re: Tables Part 1: Working With Tables Of Data

Wednesday, October 26, 2005 4:47 AM by Jim Cabel
Harlan

"As for the automatic properties you mentioned, just add a line at the bottom of a range containing either ="" or ' in each cell and with number format ;;;"_________", and always insert rows beginning with this row....

=MOD(ROW(),2)"

that sure sounds easy... NOT!

I have to say I like the idea of something that IMO should be *brain dead simple* to be *brain dead simple*. Banded rows is a canonical example of an task that frustrated the hell out of me in previous versions. The solution you mention to this problem is exactly the oppposite of simple (proof can be found in # NG questions I see on this) but was required before 12. IF these formatting smarts are as robust as they claim them to be then I'm in with both feet.

looking forward to the next post, formulas + these table things = ?

# re: Tables Part 1: Working With Tables Of Data

Wednesday, October 26, 2005 5:04 AM by Andy Cotgreave
Harlan,
Your ideas about how the extending table features are already in there are bunkum.

Sure, you can twist, turn, butcher and bodge just about anything in Excel, but to suggest that your solutions are as simple or as useful as the methods you describe is ridiculous.

You're a power user, but how many average users would be able to set up a spreadsheet like you describe?

You also give MS a hard time for using feature that are similar to Lotus. I bet you'd *also* be just as critical if MS were not updating table handling in Office 12, saying things like "How come you didn't make it more like Lotus?"

# re: Tables Part 1: Working With Tables Of Data

Wednesday, October 26, 2005 8:07 AM by Orion Adrian
Alright, here's my questions:

1) Interaction with protection (you said you'ld cover)
2) Any improvements to lookup functions with tables that will allow me to say something like:
TLOOKUP("TableName", "Criteria", "ReturnedColName")?

I'm currently doing stuff like this with VLOOKUP and MATCH. Though eventually I realized the speed was so slow I moved to a database/excel solution.

Either way, if Excel knows what a table is, it should be possible to use that implicit knoledge of what the header is so that I can act on it like I act on databases.

# re: Tables Part 1: Working With Tables Of Data

Wednesday, October 26, 2005 8:47 AM by Jim Rech
Great stuff, David!

I know I'm looking ahead but seeing "Remove Duplicates" on the ribbon was very exciting because it's a common NG question, as you know.

I'm also eager to learn how bottom totals will be handled. Since first grade most of us have learned that's where totals should go, even though (I think) on top makes as much or more sense.

Jim

# re: Tables Part 1: Working With Tables Of Data

Wednesday, October 26, 2005 11:39 AM by headtoadie
In your coming articles please expand on the methods that users can implement to retrieve data from the table.

Currently we do (like Orion above) lots and lots of vlookup, hlookup and match formulas. A more stream-lined approach to querying tables within Excel would be enormously welcomed.

HT

# re: Tables Part 1: Working With Tables Of Data

Wednesday, October 26, 2005 11:47 AM by Colin Banfield
I would like to see some thought given to simplifying and adding flexibility to table lookup functions, for example:

1) a straightforward two-dimensional lookup (VHLOOKUP()?) function, without having to construct lookups using INDEX & MATCH functions.

2) ability to lookup parts of a large table. For example, if I have a table sorted by state in the first column with 50 records for each of 50 states, there should be an easy way to restrict the search to the portion of the table containing the state identified in the lookup value argument. This can be accomplished today with a complex formula using INDEX and MATCH. Creating names for each portion of the table and looking up on that is not a good solution.

3) ability to use formulas that evaluate to a valid table range or name, without having to use the INDIRECT function. This isn't a big issue though.

4) optional arguments in the lookup functions to specify the starting column (instead of assuming the first column, as VLOOKUP does) and direction (left to right or right to left)

5) an optional argument to make the lookup case sensitive.

All of the above can be accomplished by using a combination of various functions, but since specific table support is being added to Excel 12, it makes sense to simplify and add flexibility to table lookups. In fact, one should be able to use a single function to accomplish all of the above, with the least used lookup cases provided as optional arguments to simplify the function use.


Colin

# re: Tables Part 1: Working With Tables Of Data

Wednesday, October 26, 2005 12:57 PM by Harlan Grove
To clarify, this is not innovative functionality. It may be useful functionality. It *WAS* useful functionality for some when Lotus introduced query tables in 123R8. It may have been useful in XL11 as lists. If it's becoming more intuitive, good. The comments about using XL12 tables as if getting external data are VERY WELCOME *if* that means using SQL queries of worksheet ranges to produce other worksheet ranges without the current hassles involved in doing that.

One thing 123's query table functionality provided that was pretty useful: query tables were automatically named, and other parts of 123 that accepted ranges or range names as arguments or parameters accepted query table names as well. Will XL12 automatically name tables (Table1 is as acceptable as Sheet1 as default naming)? Can XL12 tables be used everywhere range references can? If not, will they at least be directly usable in worksheet functions (as arguments)? If not, will there be some means (a new function) to convert them to arrays in formulas? If not and if a table appears to cover the cell range A1:D20, but the table can't be referenced directly in formulas, what would =COUNTA(A1:D20) return?

I would point out that many people thought merged cells were a great idea back in XL8 (97). It's not clear that they're ONLY useful for storing text constants since merged cells are incompatible with much (most?) of Excel's menu commands and many formulas. New functionality isn't always good. Experience shows that it's wise (though perhaps ungenerous) to speculate on the problems new functionality could produce.

That said, much of the automatic functionality that Excel has built up over the years is NOT under user control. If XL12 tables are under user control, that marks a welcome change in Excel's core design philosophy that one would hope would be extended to other, older aspects of Excel's design over time (but one hopes not too much time).

And the point about my suggestions for auto expanding ranges being obscure is every bit as fair as the counterpoint about having to rename .CSV files as .TXT files in order to trigger the text parsing wizard on opening such files. If one is rubbish, so's the other.

I'm *NOT* suggesting Microsoft change default functionality, but it'd be VERY WELCOME if more of Excel's functionality were optional and some aspects of default functionality could be disabled.

# re: Tables Part 1: Working With Tables Of Data

Wednesday, October 26, 2005 1:26 PM by Orion Adrian
1) Will there be the ability to reference parts of a table through its name? Can I use a function to get the header row or total row returned as a range?
2) Are we going to be able to respond to events triggered by the table like row deleted, row edited or row inserted?
3) What happens to a styled table with a border around it when I add a row? I'm assuming the border moves. Are there times where the border behavior is non-intuitive or incorrect?

# re: Tables Part 1: Working With Tables Of Data

Wednesday, October 26, 2005 1:29 PM by Harlan Grove
Colin Banfield...
...
|1) a straightforward two-dimensional lookup
|(VHLOOKUP()?) function, without having to
|construct lookups using INDEX & MATCH
|functions.

Like 123's old @XINDEX function.

|2) ability to lookup parts of a large table.
|For example, if I have a table sorted by state
|in the first column with 50 records for each
|of 50 states, there should be an easy way to
|restrict the search to the portion of the
|table containing the state identified in the
|lookup value argument. This can be
|accomplished today with a complex formula
|using INDEX and MATCH. Creating names for each
|portion of the table and looking up on that is
|not a good solution.

You could use SQL.REQUEST. Something like

=SQL.REQUEST("DSN=Excel Files;DBQ=<filename>",,,"SELECT Sales FROM Table WHERE State='WV' AND Qtr='2005Q2'")

It'd be VERY WELCOME INDEED if XL12 were to provide an improved SQL.REQUEST that defaulted the first argument to the Excel workbook containing the formula making the SQL.REQUEST call.

Some may believe SQL is difficult, so functions like SQL.REQUEST aren't really accessible to most users. Have they ever tried showing new Excel users how to set up criteria ranges for advanced filters?

|3) ability to use formulas that evaluate to a
|valid table range or name, without having to
|use the INDIRECT function. This isn't a big
|issue though.

How could you ever resolve whether to treat strings as strings or as implicit references? Would that only apply to return values from formulas or would string constants be parsed as potential references? For example, should the formula

="A"&MID("12345",3,2)

return the text "A34" or the value of cell A34? While the intended use might be clear in

=INDEX("A1:"&"A"&MID("12345",3,2),i,j)

it'd be less so in

=LEN("A"&MID("12345",m,n))

|4) optional arguments in the lookup functions
|to specify the starting column (instead of
|assuming the first column, as VLOOKUP does)
|and direction (left to right or right to left)

Use SQL.REQUEST.

|5) an optional argument to make the lookup
|case sensitive.

Again, use SQL.REQUEST - it's case-sensitive by default, so use LCASE(FieldName) in the WHERE clause for case-insensitive criteria.

This raises the question whether it'd be easier to add arguments to VLOOKUP to return, e.g., the 2nd column/field from a table corresponding to the MAX value of the 5th column/field of that table or just use SQL.REQUEST.

I've argued that there are things spreadsheets do better than databases in newsgroups, but there are also things databases do (much) better than spreadsheets. General lookups are one of those things. {V|H|}LOOKUP functions will always be kludges.

But, in the spirit of SUMIFS etc., there could be VLOOKUPS:

VLOOKUPS(ResultColumn,LookupType,LookupValue1,LookupColumn1[,LookupValue2,LookupColumn2,...])

or maybe that should be

VLOOKUPS(ResultColumn,LookupValue1,LookupColumn1,LookupType1[,LookupValue2,LookupColumn2,LookupType2,...])

# re: Tables Part 1: Working With Tables Of Data

Wednesday, October 26, 2005 3:54 PM by Jean-Marc Decouleur
Hi David,

If a table has 2 columns with headers called 'Price' and 'Quantity'. Will it be possible in a third column of the table to use formulas like '=Price * Quantity' for all rows (of this third column), without having to define any named range ?

Jean-Marc

# re: Tables Part 1: Working With Tables Of Data

Wednesday, October 26, 2005 4:20 PM by Colin Banfield
Harlan, SQL.REQUEST for retrieving a single value from a relatively small workbook table to use in a formula? Seems like an inappropriate use of the function.

VLOOKUPS has much of the required syntax but it would be simpler to just call the function "LOOKUPS"


Colin

# re: Tables Part 1: Working With Tables Of Data

Wednesday, October 26, 2005 4:46 PM by Harlan Grove
Colin Banfield...
|Harlan, SQL.REQUEST for retrieving a single
|value from a relatively small workbook table
|to use in a formula? Seems like an
|inappropriate use of the function.

Depends. If it were reengineered for greater efficiency in intraworkbook calls, it'd certainly be the most flexible tool for general lookups.

|VLOOKUPS has much of the required syntax but
|it would be simpler to just call the function
|"LOOKUPS"

Then what's the equivalent for HLOOKUP? Or would the function need to figure that out from the shape of the first argument?

# re: Tables Part 1: Working With Tables Of Data

Wednesday, October 26, 2005 5:08 PM by Colin Banfield
<<Then what's the equivalent for HLOOKUP? Or would the function need to figure that out from the shape of the first argument? >>

Don't want to hog the discussion over this thing but LOOKUPS would be a general two-dimensional lookup function with arguments for row and column lookups. Depending on the row or column lookup arguments that are left blank, the function becomes a V or H lookup.

# re: Tables Part 1: Working With Tables Of Data

Wednesday, October 26, 2005 9:32 PM by Jean Martineau
Tables of data are going to be another big improvement for non advance users. Great job.

As you were expecting David, tables of data are going in the same direction of my last posts.

|Automatically extended to the new row
is answering my "Dynamic Ranges" post. I just hope this automatically extended feature could also be an option for Defined Names.

|tables and formulas collide
will probably answer my "HEADER FORMULA" post: if a formula in a column is part of a table, the formula will automatically extended to new rows. I’m eager to read your explanations on this.

Like others have already mentionned it, I just hope we can use header names in formulas as if there were Defined Names and that we can have easier new functions to retrieve data from a table.

Thanks again for your blog,

Jean

# re: Tables Part 1: Working With Tables Of Data

Wednesday, October 26, 2005 10:06 PM by Jean Martineau
I just forgot this: could the resize handle be also available in the lower-LEFT corner of the table if it's not already there ?

Jean

# re: Tables Part 1: Working With Tables Of Data

Thursday, October 27, 2005 1:50 AM by David Gainer
Hello folks – everyone, as always, thanks for the feedback, comments, requests, and kind words.

Orion, headtoadie, Harlan – Yes, you will be able to reference tables and columns and more by name. More on that in two posts.

Jim – I will try and get to remove dupes in the next week or so. Remind me next week if you don’t see something by a week Friday ;-)

Orion – Yes, the border moves appropriately when you add rows or columns. I don’t believe that there are times when the border behaviour is non-intuitive.

Jean-Marc – Yup, more on that in two posts.

Jean – There is a resize command that allows resizing in any direction (check out the ribbon picture I posted), but I will also pass along your comment to the appropriate designer.

# re: Tables Part 1: Working With Tables Of Data

Thursday, October 27, 2005 11:38 AM by Helen
I must say I am also somewhat sceptical of anything where Excel tries to second-guess my actions, and tend to turn these off, but I'm definitely willing to give this a chance.

This has probably been said already (so many comments here that I don't have time to read them all!) but multi-column lookups and extracts would be my #1 wish for tables. DGET() works with multi-column criteria but can only retrieve a single row, so intricate workarounds with INDEX()/MATCH() are needed now.

Also, how much of the table functionality will be controllable by VBA? Can I refer to Worksheets(x).Tables(y)? Will the table "auto-extend" when worksheet cells are changed through VBA?

# re: Tables Part 1: Working With Tables Of Data

Thursday, October 27, 2005 12:36 PM by David Gainer
Hi Helen - yes, there is a OM for tables along the lines of what you suggest. Tables will auto-expand when worksheet cells are changed through VBA.
New Comments to this post are disabled
 
Page view tracker