J
johan dekyvere
why still limit the use of more than 65000 lines in excel ?
With actuel memory, there should be no more problems ??
With actuel memory, there should be no more problems ??
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
A
Arvi Laanemets
Hi
2^16=65536
2^16=65536
J
JE McGimpsey
The problem isn't memory, it's the application code that's used to
reference rows. There are millions of lines of code in XL, of which a
substantial number depend on two-byte row references. Two bytes, or 16
bits, represents 2^16, or 65536 rows.
Changing that code is a monumental task: man-centuries of coding, and
especially, testing. A task which, to date, apparently hasn't been shown
to be worth doing. Of course, from MS's perspective,it's only worth
doing if (a) it results in enough additional sales to cover the cost
(very unlikely - how many new copies would your business buy, especially
if the change broke the file format that allows
XL97/98/00/01/02/v.X/03/04 versions to share files?), or (b) there's a
structural reason to do so (e.g., implementing a new platform requires a
complete rewrite anyway, and the change can be accommodated with
relatively little additional expense, which again, file/backwards
compatibility makes unlikely), or it's done as a very long-term
strategic move.
In addition to file compatibility, there's a huge code base of VBA
applications which, rightly or wrongly, are based on 65536 rows. MS
risks breaking those applications, and therefore losing sales, to
businesses that require those applications.
In addition, the vast majority of needs for more than 2^16 rows are for
databases, which are better handled in a database application.
reference rows. There are millions of lines of code in XL, of which a
substantial number depend on two-byte row references. Two bytes, or 16
bits, represents 2^16, or 65536 rows.
Changing that code is a monumental task: man-centuries of coding, and
especially, testing. A task which, to date, apparently hasn't been shown
to be worth doing. Of course, from MS's perspective,it's only worth
doing if (a) it results in enough additional sales to cover the cost
(very unlikely - how many new copies would your business buy, especially
if the change broke the file format that allows
XL97/98/00/01/02/v.X/03/04 versions to share files?), or (b) there's a
structural reason to do so (e.g., implementing a new platform requires a
complete rewrite anyway, and the change can be accommodated with
relatively little additional expense, which again, file/backwards
compatibility makes unlikely), or it's done as a very long-term
strategic move.
In addition to file compatibility, there's a huge code base of VBA
applications which, rightly or wrongly, are based on 65536 rows. MS
risks breaking those applications, and therefore losing sales, to
businesses that require those applications.
In addition, the vast majority of needs for more than 2^16 rows are for
databases, which are better handled in a database application.