In a recent forum thread, someone asked to see who created/altered a particular object. Starting in SQL Server 2005, this information is contained in the default trace, provided that the default trace is enabled and the information hasn't rolled out of the trace files. The catch is how to report on the information easily. If you've used it before, you're likely thinking of the Schema Changes History report. The catch is that if you're using SQL Server Management Studio from SQL Server 2005, this functionality wasn't available until Service Pack 2. So if you have just installed the workstation tools and you've never applied a service pack, you won't see the option for the reports because it's not there. The same is true if you have a full SQL Server installation that's still RTM or SP1. The only way you see the change to SSMS is to apply SP2.

Which brings up a good point. You should be applying service packs to your client systems as well. This was a lesson we learned the hard way on SQL Server 7. It seemed like with every new SQL Server service pack, the definition of DTS packages changed. The only exception was if you encrypted your DTS packages with a password. That didn't change. And so what it meant was if you had different SP versions between your servers and your client systems creating said packages, you had a problem. Because ones with later service packs could read packages created with older service packs, but not vice versa. And as I'm writing this, Aaron Bertrand has just put out a blog post talking about an SSMS issue that is fixed with a hotfix, which you should take a look at, especially if you're dealing with mixed environments. So the point here is that in addition to keeping your SQL Servers up to date. you also need to plan on keeping your SQL Server client tools up-to-date as well. Not only are new features provided, but fixes are included with the updates, too.