Solution:
In Management Studio, Tools –> Options then go to the Designer Page and uncheck “Prevent saving changes that require table re-creation”.

Solution found at: http://pragmaticworks.com/community/blogs/brianknight/archive/2008/06/04/sql-server-2008-designer-behavior-change-saving-changes-not-permitted.aspx

After a bit of Binging I found this thread: http://social.msdn.microsoft.com/forums/en-US/sqlsetupandupgrade/thread/ca182f5d-114a-4516-99d4-0854ad176fbf/

It talks about deleting any registry settings with a value of “PendingFileRenameOperations" in the key “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager"

Open your Windows programs type “regedit.exe” in the search then click enter. Now drill down to the Session Manager key.  Look for any value with “Pending FileRenameOperations” and delete it.

Go back to the SQL Server 2008 setup and rerun it.  Everything should pass now and you can proceed.

Lets say you have a table “Property” with a primary key of “PropertyId”.  In the table definition it is set as a unqueidentifier and by default it is assigned a NewID().

Now go to your Linq to Sql and create your dbml, drag your Property table into it.

In order to have the PropertyId generated using the Default Value go  to the properties of the PropertyId field and set Auto Generate Value to True and Auto-Sync to OnInsert.

I am sure many already know this, but I hope it can help save some time for others. 

I uploaded it to the server then went to restore the db on the server, that is when I received this error:

Solution: The location of where my database on my local machine was different than that on the server.  I had to update the database location on the server. 

This was done by when restoring clicking on the options tab.  Then updating the paths of the Original File Name to where the database data is stored on the server.  I found this path out by looking to see where the current ones were stored.

I created an Admin interface for one of my clients that basically manages an Image Gallery. The gallery allows for a Category and SubCategory structure.

I received a call at about 10:30am asking where all of his images were?  After doing some investigating, my heart stopped, I found the bug.

I had a bug in my SubCategory_Delete proc that didn’t have the WHERE SubCategoryId = @SubCategoryId clause. When a user would delete a SubCategory it would delete all the photos in the image gallery instead of just the photos in that specific SubCategory.

My initial thought was to get the backup.  Well it turns out backups aren’t created automatically.  This is something you need to manual do when creating a database.

I was fortunate enough to have a great Customer Service rep, Sean Fox, that somehow managed to convince MOSSO’s IT team to create a backup for me from their disaster recovery backups.  Thanks MOSSO.

So after first going to my client with my tail between my legs I was able to go back to him as a hero. “Your data has been saved!”

I’ve since put in place a backup plan for all of my databases hosted at MOSSO.  I found this article in their Knowledge Base: http://help.mosso.com/article.php?id=346 for MSSql. There is one for MySql, http://help.mosso.com/article.php?id=356.

I modified it a bit by creating a console app that is scheduled nightly and ran on my server.  This way only I can execute the backup.

My advice is to put this in place before you need it, not afterwards.