Entity Framework: duplicate rows in resultset from a view

After including a view I have in my database in an Entity Framework data model, I noticed that for some strange reason, the result was showing duplicates. When a set should have for instance 10 different rows, it might contain only 4 different rows, some of which were duplicated so it was still a total of 10 rows.
The view itself showed the correct results, but when called from code using the Entity Framework, it once again showed the wrong results.
After some testing I found out that the rows that were duplicated, were rows that shared certain values with the rows that were replaced by it. After checking this in my Entity Model, I soon found at that the Entity Model has a strange way of handling rows with equal primary key values.

I'll try and explain my findings:

aspnet_regsql.exe doesn't work with SQL Azure

If you want to create the database structure for using Forms Authentication in your Windows Azure hosted ASP.Net application, you'll probably have noticed that running aspnet_regsql.exe on your Azure database doesn't work.
I have tried merging a local database using Red Gate SQL Compare 9 (you can of course also use the SQL Azure Migration Wizard), but that also gave me some errors regarding some elements in the resulting update statement that were not supported in SQL Azure.
I have looked into these errors and found that it was relatively easy to fix these. If you take a look at the Stored Procedure called aspnet_Membership_GetNumberOfUsersOnline in a "regular" SQL server, you'll see that it contains a couple of (NOLOCK) statements in it's SELECT statement.

Reseed a table in SQL Server

In Microsoft SQL Server, it is possible to reseed an identity column of a table. If you want to start an identity column at a different value (for instance, after clearing it), you can use the following syntax:
DBCC CHECKIDENT (myTable, reseed, 0)

The next row that is added to the table will have 1 in its identity column. If we would use

DBCC CHECKIDENT (myTable, reseed, 41)

the next row would get 42 in its identity column.

Be careful when using this on tables with rows in them, if the new seed is lower than the highest currently in the table, you will encounter problems before long. When the new seed is already in use, you will get a unique key restriction violation on insert!

Getting the ISO weeknumber in SQL Server 2005 (and earlier)

I just discovered that SQL Server often returns the wrong week number when using DatePart(wk, @date).
For instance, SELECT DatePart(wk, '2010-12-17') returns 47 while it should be 46.
This is because SQL Server starts counting weeks from 1 Jan, so 1 Jan is always in week 1 of the year.
The ISO standard states that week 1 is the first week with 4 days in it.
The following code can be used (with @date being the datetime) to return the ISO week

CREATE FUNCTION GetISOWeek(@date DateTime)
RETURNS INTEGER
AS
BEGIN
  declare @ISOweek INTEGER;
  select @ISOweek = datepart(wk ,@date) + 1 - 
    datepart(wk, 'Jan 4,' + CAST(datepart(yy, @date) as CHAR(4)));
  if (@ISOweek = 0)
    select @ISOweek = datepart(wk, 'Dec ' + CAST(24 + 
      datepart(day, @date) AS CHAR(2)) + ',' + 
      CAST(datepart(yy, @date) - 1 as CHAR(4))) + 1
  RETURN @ISOweek
END
GO
(From windowsitpro.com)

Since SQL2008, DatePart supports the ISO Week, by calling:
DatePart(isowk, @date) or  DatePart(isoww, @date)