Couple of items to note all of which assume a SQL 2005 platform as you say this code is for:
1) The call to DBCC UPDATEUSAGE in your ‘proc_records_per_database’ SP is unnecessary per BOL which states “Databases created on SQL Server 2005 should never experience incorrect counts, however, databases upgraded to SQL Server 2005 may contain invalid counts. We recommend running DBCC UPDATEUSAGE after upgrading to SQL Server 2005 to correct any invalid counts.” So you may need to run it the first time you access DB’s upgraded from 2000 to 2005 but after that initial run this is just excess overhead.
2) Per BOL regarding sysindexes “This SQL Server 2000 system table is included as a view for backward compatibility. We recommend that you use the current SQL Server system views instead.” The older SQL 2000 sysindexes is replaced with sys.indexes . Unfortunately the newer sys.indexes does not include rowcount however you can get it thru the SQL 2005 view sys.partitions but if you link it to sys.indexes you’ll need to eliminate the duplication that you get joining the 3 items (sys.tables, sys.indexes & sys.partitions)
3) Even though you managed to avoid the literal use of a cursor you have 4 instances of RBAR (row by agonizing row) where you’re looping through some set/results.
4) It may be just me but it seems like there’s a lot going on here just to get the table name, rowcounts and space used. It does do it for all databases if one wishes however if one’s only looking for this info on a single DB which I think would be the more common scenario you can do this thru the join of sys.tables + sis.indexes + dbo.spt_values (located in the MASTER DB).
This is just my opinion.
Just say No to Facebook!