I wonder nobody else has reported this problem yet (or did?): after upgrading DNN 3.1. to DNN 3.2. and installing .NET framework 2.0 and DNN 4.0, both DNN installations report a SQL error "@TimeZoneAdjustment is not a parameter for procedure aspnet_Profile_GetProperties".

The matter is, that the .NET framework 2.0 has changed the last parameter in the stored procedures aspnet_Profile_GetProperties and aspnet_Profile_SetProperties from @TimeZoneAdjustment int to @CurrentTimeUtc date between BETA2 and Release, as John Brennan describes on http://www.irishdev.com/blogs/jbrennan/archive/2005/11/02/1036.aspx.

Now in the DNN 4.0 Providers\DataProviders\SqlDataProvider directory, there are partitially Installxxx.scripts using the old version with the @TimeZoneAdjustment parameter, but the installation script 04.00.00.SqlDataProvider itself installs both procedures in the new fashion with the @CurrentTimeUtc parameter.

My workaround was to re-run the Installxxx.scripts, installing the older BETA 2 versions with the @TimeZoneAdjustment parameter. Anyway, I'm curious which next installation will rewrite it again and couse the DNN not to work.