Eric Sink, the founder of SourceGear, provides an excellent set of articles on the fundamentals of using source control.  Quoting from his introduction:

Our universities often don't teach people how to do source control.  We graduate with Computer Science degrees.  We know more than we'll ever need to know about discrete math, artificial intelligence and the design of virtual memory systems.  But many of us enter the workforce with no knowledge of how to use any of the basic tools of software development, including bug-tracking, unit testing, code coverage, source control, or even IDEs.

Our employers don't teach people how to do source control.  In fact, many employers provide their developers with no training at all.

I've certainly seen this to be the case with a number of my clients.  Eric's HOWTO should be required reading for any developer, even if you work as a team of one.

Recently one of my clients deployed an ASP.NET web application to their public web farm.  Since this application made use of session state, they elected to store the session data in SQL Server.  The application ran fine for a couple months but then began exhibiting some problems.  Specifically, the following errors occurred:

SELECT permission denied on object 'ASPStateTempApplications', database 'tempdb', owner 'dbo'.
INSERT permission denied on object 'ASPStateTempApplications', database 'tempdb', owner 'dbo'.
SELECT permission denied on object 'ASPStateTempApplications', database 'tempdb', owner 'dbo'.

and

System.Data.SqlClient.SqlException: A severe error occurred on the current command.  The results, if any, should be discarded.
   at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream)
   at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
   at System.Web.SessionState.SqlStateClientManager.SetAsyncWorker(String id, SessionStateItem item, Byte[] buf, Int32 length, Boolean inStorage)

Unfortunately, a search of the Microsoft KnowledgeBase didn't turn up any results.  Time for some old-fashioned sleuthing!

I found an article by Barry Dorrans that pointed to the problem being the "Cross-Database Ownership Chaining" feature and its change in behavior starting with SP3 for SQL Server 2000.

In addition to the information found there, I also discovered (thanks to Carl Prothman) that the database owner of the ASPState database still needed to be set to "sa" even if trusted connections were not being used.

To roll the whole thing up, I created the following script to set the necessary permissions for the database and to set the options referenced above.  You'll need to change all references to "aspnet_user" to the appropriate SQL Server login on your server.

            USE master goEXEC sp_dboption 'ASPState', 'db
chaining', 'true'goUSE ASPState GO sp_changedbowner 'sa','true'GO sp_grantdbaccess 'aspnet_user', 'aspnet_user'GOGRANTEXECon TempGetAppID to aspnet_user GRANTEXECon TempGetStateItem to aspnet_user GRANTEXECon TempGetStateItem2 to aspnet_user GRANTEXECon TempGetStateItemExclusive to aspnet_user GRANTEXECon TempGetStateItemExclusive2 to aspnet_user GRANTEXECon TempInsertStateItemLong to aspnet_user GRANTEXECon TempInsertStateItemShort to aspnet_user GRANTEXECon TempReleaseStateItemExclusive to aspnet_user GRANTEXECon TempRemoveStateItem to aspnet_user GRANTEXECon TempResetTimeout to aspnet_user GRANTEXECon TempUpdateStateItemLong to aspnet_user GRANTEXECon TempUpdateStateItemLongNullShort to aspnet_user GRANTEXECon TempUpdateStateItemShort to aspnet_user GRANTEXECon TempUpdateStateItemShortNullLong to aspnet_user GO

Hopefully Microsoft will address this issue with a KnowledgeBase article soon!