See that big white space? That is where you put the DETAILS of your
question for which the Subject header is merely an introduction.
So for WHICH version of Outlook are you asking?
Versions 2000 and earlier supported a maximum of 16,384 records (items
in the database which include folders, calendar events, journal entries,
e-mails, tasks, and contacts). If you select the "Allow upgrade to
large tables" option in version 2000, or earlier, the maximum goes to
65,536 items total in the message store. As of version 2002, and for
later versions that use the ANSI file format, this option is not shown.
Instead Outlook automatically upgrades to using large tables when the
total number of records exceeds 16,383.
ANSI .pst files had 32-bit headers. The later Unicode .pst files have
64-bit headers. The Unicode .pst format available in OL2003, and later,
defaults to an initial maximum filesize of 20GB but can go up to 33TB
(via registry edits). I believe the total number of records in a
Unicode .pst file is 128 million.
After more than a decade, Microsoft still refuses to publish a binary
file specification for their PST files although they do publish them for
other binary file formats. See:
http://www.microsoft.com/interop/docs/OfficeBinaryFormats.mspx
http://www.microsoft.com/interop/osp/default.mspx
where you will notice their PST format has no published specification.
There is a library available for programmers that want to directly
access the .pst files without using Outlook as a 3rd party broker to
handle managing the database. There is a link at that project page
describing the format of the records in the .pst database file. While
the ANSI format is the 32-bit format, apparently only 16 bits are
available for indexing entries (2^16 = 65,536). In Unicode format that
went to 64 bit lengths for headers, index addressing seems limited to 32
bits but 4 of them are zeroed leaving only 28 bits. While 2^28 =
268,435,456, I've heard the limit was half that (maybe they screwed up
and used a signed integer for the field type). The libpst document for
..pst format says, "So far we have only described internal index
references where the high order 16 bits are zero. That suffices for
single descriptor blocks. But in the case of the type 0x0101 descriptor
block, we have an array of subblocks. In this case, the high order 16
bits of an internal index reference are used to select the subblock.
Each subblock starts with a 16 bit indexOffset which points to the count
and array of 16 bit integer pairs which are offsets in the current
subblock." Okay, then that makes 32 bits total (16 for the offset
within a block and 16 for identifying the block).
Maybe someone else more familiar with the header and record layout
specification for a binary tree database file format can decipher what
the libpst document says. With the ANSI .pst file, you get 65,535 items
total in the database. With the Unicode .pst file, you get 134,217,728
or maybe 268,435,456 - but it really doesn't matter because I doubt any
user, even a corporation, would generate that many records in the .pst
database file and still be able to use it due to severe slowdown in
accessing the records within it). Doable doesn't mean usable.
