.NET Framework 4.0 and Visual Studio 2010 Training Kit

I’m still digesting the changes in .NET 3.5 and SP1, and the guys from Redmond already make a training kit for the next version of the framework. It’s impossible to follow this pace of changes 🙁

The Visual Studio 2010 and .NET Framework 4.0 Training Kit includes presentations, hands-on labs, and demos. This content is designed to help you learn how to utilize the Visual Studio 2010 features and a variety of framework technologies including: C# 4.0, Visual Basic 10, F#, Parallel Computing Platform, WCF, WF, WPF, ASP.NET AJAX 4.0, ASP.NET MVC Dynamic Data.

Get it from http://www.microsoft.com/downloads/details.aspx?FamilyID=752cb725-969b-4732-a383-ed5740f02e93&displaylang=en

NumberField and getElementById

Just a quick lesson learnt today in field:

SCENARIO

You want to use JavaScript to validate certain fields when the SharePoint page is in Edit Mode. You use Control.ClientID ASP.NET property to emit the control ID from the server-side code using Page.ClientScript (usually in PreRender event). You’d usually use this ID to access the control on the client side using document.getElementById.

PROBLEM

I had issues with NumberField (the server-side control that is used to render a numeric column in SharePoint). Its ClientID property is not the same as the one that is finally rendered back. In fact, it’s a child control, two levels down from the NumberField. The reason for this behaviour is that NumberField is a composite templated control, with multiple child controls that compose it.

SOLUTION

Instead of using:

numberFieldCtrl.ClientID

use

numberFieldCtrl.Controls[0].FindControl("TextField").ClientID

to get your correct control ID for JavaScript validation code on the page.

Truncate that Huge DB Transaction Log!

How many times you’ve seen the small SharePoint content database and a huge transaction log by its side? And the corresponding “Not enough storage space” warning on the SQL Server?

The cause of this behaviour is that the SharePoint databases are created with FULL RECOVERY transaction log. It essentially creates a full record of every sentence sent to the database, even if it’s only a SELECT. As you can imagine, SharePoint does a lot of querying to the database every second and the transaction log grows very quickly indeed.

To prevent this behaviour, change the RECOVERY mode of the transaction log to SIMPLE. But, if you are coping with a huge transaction log already, you can use this snippet of T-SQL to truncate it back to inoffensive 1 MB in size:

(of course, being WSS_Content_DB your database name).