You can use your favorite social network to register or link an existing account:
Or use your email address to register without a social network:
Sign in with these social networks:
Or enter your username and password
Forgot your password?
Yes, please link my existing account with for quick, secure access.
No, I would like to create a new account with my profile information.
When we started Excel 2007, we made a decision that as part of increasing the grid size, we were going to address a lot of important other “limits” in the product. The entire list can be seen here, in the second post I ever made to this blog. (Note, this is probably a good place to note that we had to back out the change to “The number of characters that can be stored and displayed in a cell formatted as Text” recently – we found a problem with the implementation that couldn’t be fixed at this late date, so we are going to address it next time.)
When we developed the list of limits to address, we approached the research a few different ways. We tried to identify anything that would prevent users from using the “big grid” to its fullest. We tried to address top customer requests, whether they came from our support team, the newsgroups, web searches, and the like. We talked to our large enterprise customers and developers. We went through old support records. Etc. Having done that, and made a lot of changes in Excel 2007, we have already started to identify candidates for the next version – for example, the number of discontinuous ranges that can be selected, the number of categories shown in the function dialog, etc.
What else would you like to see us work on in this area? Are there any limits that you run into frequently that you think we should try and increase or eliminate in the next version of Excel?
Comments: (24) Collapse
Gee, max no. of points in a chart series
Old Limit: 32k
New Limit: 32k
right?
It would be great if the limit of 32 cells for the Scenario Manager was updated.
Aside from increasing limits, I believe you should also address the subtle impacts of the vastly increased grid-size. I'd like to suggest some innovative use of multiple monitors so that users can install as many monitors as would help in grasping the new grid-size. For example it would be good to have a feature where you can just highlight a range of cells and a right-click option is available to open a new screen (to be maximised in a separate monitor) showing the range as the initial grid. Effectively, this would also mean that a file can be updated simultaneously in multiple sessions (or psuedo-sessions if only one instance of Excel)
I've mentioned this before.....
The physical size of the refedits in some user forms, most notably, data validation, conditional formatting, and defined names. Also, these are limited to ~255 characters. I would think that the character limit should be the same as a worksheet formula. These refedits shoud use the same behavior as the formula bar, after you've typed in so many characters the line wraps.
Number of files open with the same file name: 1
This is a problem when standardized directory structures are used, e.g.:
\FISCAL\05Q1\totals.xlsx
\FISCAL\05Q2\totals.xlsx
What if I want to compare the totals from Q1 and Q2 side-by-side in Excel?
Also, though I love the new sheet dimensions, I have gotten perilously close to the 1 million row limit on occasion. Perhaps 2^24 (16.7 million) rows in the future?
Hi David,
I have mentioned this before.....And I do hope you get this in 2007
Selecting Number of Discontinuous Cells - Currently 8912....or some crazy number like that...
Asume some one working in in 007 with 100,000 rows filets on a criteria... Good chances that he will get >8912 discontinuous cells...
It happens to me many times in the current version as well...
Now if you want to delete these filtered cells... you end up with an error "selection too large" and it then deletes the inbetween data as well !!!
Please remove this limit
My company and whole dvelopment team have always had the problem of the 32000 point limit per plot in Charts.
This is particularly limiting if you are handling long time series as we do.
Financial users doing any analytics are completely stopped by this limitation.
If not too late PLEASE cqan we have the new limit up to say as close to the 1 million row limit as possible?
This would allow the plotting stock tick data for a larger number of days. With current transaction volume exploding (extimated to double by end of 2007) this problem is escalating.
I am aware of quite a number of colleagues in the financial sector espectially algorithmic tradyng analytics who need this limit expanded.
Would be grateful if it would be possible to have a response to this plea......
Best Regards,
Ed Leshik
There seems to a limit to how many hidden columns with comments in them. It may be a bug.
For us (big financial services organization) the biggest problem we anticipate with increased grid size is exponential increase in file instability. Currently we have major problems with the same workbook corruptions everyone's been having since Excel 5 (and maybe even earlier - that's just when I joined the workforce) - namely the 'last cell' jumping way beyond where anyone has ever typed (and associated file bloat), corrupt named ranges, corrupt styles, etc. We'd *really* like to see some serious work on this, otherwise we expect things to get much, much worse with a bigger grid to get messed up. We have tools for checking and fixing file integrity in Outlook, how about some equivalents for Excel? Especially to work with the binary formats which we'll be stuck with in compatibility mode for probably about a year, and a lot of our people will probably continue using even longer for performance reasons...
Sorry to sound so negative - I love what you're doing and really look forward to seeing Office 2007 going into production, but this is a HUGE concern for us!
I wonder why there are still limits at all.
BIFF12 uses more var-length encoding than BIFF8, so if the serialization is any sign of how run-time structures are kept, why don't you make a large step forward instead of only a tiny step?
Anything from rows to columns to how many filters this particular object supports, can be subject to var-length encoding and thus support virtually no limit, including the typical 32-bit pointer limits.
Time for code refactoring...
I'd like to support the 'no limits' view.
1 million rows is a lot better than the current limits, but still limits use.
Example: I currently need to check the last few records of a large tab-separated text file. Eventually I'll write code to pull it into a database, but what I need to do today is check that the format is right, including the footer record. Unfortunately it's over 2 GBytes in size, and several million records long. It would be so nice if I could load it into Excel to check it, rather than having to write code just to see what's there!
[No, it won't load in Word either].
This is really a commment on "The percentmin Property" where comments are now disabled.
The 10% default option is the stupidest idea I have ever heard proposed in software design. Without exception. And I have heard a lot. It is just plain WRONG!!! What the hell were you guys thinking???
How about the limit on the number of toolbars, apparently now reduced to one?
Another limitation I would like to see eliminated is somewhat beyond the scope of the size limits under discussion here, but this seems a good place to bring it up. Most functions representing operators that are both associative and commutative, e.g. SUM() and OR(), accept ranges as arguments. I would like the ability to use ranges as arguments to functions that are associative but not commutative, e.g. CONCATENATE(). To eliminate ambiguity this could be restricted to one-dimensional ranges, or could be arbitrarily defined to work in row-major or column-major order.
I would love to have the ability to write the result of grouping in a pivot table to a new column in the underlying data. For example, if I have a set of students with grad yr=06 and and another group with grad yr=06J, I'd like to be able to group them in a pivot table, rename the column as 2006, and then have the ability to add a column that will contain "2006" in the underlying data. I realize this isn't a limit exactly, but I'm taking the opportunity to ask for something I need. Thanks!
I cant remember clearly whether you covered it or not before, but Pivot Table unique items limit of 8000 is very far behind need. Should be as limit as the row limit for display.
Sorry if this is a request already addressed.
Comments: (loading) Collapse