The fillfactor setting for a clustered index on IDENTITY field can be set extremely high (95% - 99%), since there it is HIGHLY unlikely that a clustering key will be updated, causing a possible page split. Probably the best bet is to leave the setting at the default of 0, which has the result that Allen stated. Bear in mind, however, that the fillfactor DOES NOT affect future index pages, only currently existing ones.

--

Putting a clustered index on an IDENTITY field for highly transactional tables can actually be a good idea, since it generally forces a hot spot on the disk. Contrary to the beliefs held by some developers and DBAs who can't seem to get 6.5 out of their minds, a hot spot can be quite desirable for SQL2K (and 7.0) OLTP and mixed OLTP/OLAP databases, because it increases the chance that needed extents will already be spooled into cache; any extents already in cache will, of course, be retrieved much faster than reading from disk. Since 7.0, row-level locking has nullified the previously valid assertion that hot spots were bad because of locking concerns.