ITWriting.com has an interview with Euan Garden about what's new in SQL Server Yukon. This article has more details than many others I have seen.
Like I had suspected earlier, the XML capabilities in Yukon are really going to put the pure XML databases out-of-commission, with a native XML data type, full support for XQuery and various other XML standards, and field indexing that is "magnitudes faster" than the current performance of XML-based operations.
Microsoft also plans to ship Objectspaces with Yukon. Objectspaces is an object-relational persistence framework. You set up the mapping of objects to tables, and from then on you just call the Objectspaces API. This will likely put many object-oriented databases out-of-commission as well. There never really was a need for OO databases, it was just some vendors cashing in on the OO trend. The relational model is based on proven scientific theory, whereas OO databases were based on buzzword compliance.
MSDN is starting to publish 2 articles per month from SQL Server magazine. There's no link, but the articles appear in the MSDN Just Published RSS feed. I've had a subscription up until now (when my free year for getting my MCDBA ran out) and it is a good magazine if you are in SQL Server all day. Not to knock it since I work with SQL Server a lot, but not enough to warrant spending the money on the magazine.
SQL Server Books Online (you'll often see it abbreviated BOL), updated for SP3, is one of the best references you can get and covers 95% of what you need to do. Book-wise, Admin911: SQL Server 2000 is great for admin topics (I used it to study for exam 228) and to really get into the details there is the preeminent Inside Microsoft SQL Server 2000 by Kalen Delaney.
One of the best ways to figure out what is going on with an application is to see what calls it is making to a database (or multiple databases). Traces quickly and easily give you an overview of all the database activity resulting from a single form. I usually start up SQL Profiler and run a trace on the database the application is hitting so that I can see exactly what an individual form is doing. I am going to explain this in reference to a web application (since that is where my experience comes from), but this is applicable (and the process should be identical) to Windows Forms as well. The common basis here is the SQL Server database.
First, start up SQL Profiler. If you have SQL Server, this should be installed. To get to it, go to the Start menu/Programs/Microsoft SQL Server/Profiler. This will open a blank SQL Profiler.
Next, create a new Trace. Go to File/New/Trace, and then select the SQL Server you will be running the Trace on, and select the appropriate authentication. Note that you must have sufficient privileges to do this. This will open the Trace Properties window. You can enter a name if you want to save the Trace, but for a quick-and-dirty look, you can ignore it.
Click on the Filters tab. Here you can narrow down what the Trace pulls back. The "Application Name - Like" filter captures the name of the application that is actually executing the query, most of the time this will be ".Net SqlClient Data Provider" if you are using the SqlClient namespace, so this is not all that useful. A better way to filter the results, if you want to see a specific database's activity, is to filter with "DatabaseName - Like". You can use the "Not like" filter to specify what you don't want.
Finally, pull up the web form you are interested in and the results window shows you tons of stuff. The Trace will show every SQL command issued against the database and the value of any parameters. You can also see the number of Reads and Writes to get a sense of which queries are taking the most time on a page. These are just the basics.
Note: I had images to show what the windows looked like, but I cannot currently upload images. If the instructions are unclear, leave a comment and I'll try to answer it.