Every Database Management System supports default values; whenever a field is left out of an insert statement, the database automatically inserts a default for that row/column. This saves some time, especially when entering data manually into the database. However, there is a challenge with this: default values do not seem to work well in LINQ. Let me explain.

Suppose you have a column (CreatedDate) in the database system that uses the datetime SQL Server data type. This translates to DateTime in the .NET framework, and is required and has a default value of getdate(). The challenge is this: by default, a DateTime value is represented as a value of "1/1/0001" in the .NET framework. This is a valid date and the database system tries to supply this date to SQL Server in the insert.

SQL Server rejects this value because the created date should be a value between 1/1/1753 and 12/31/9999 for the datetime type, which causes an exception and unfortunately no details about the business object type name or property name are provided, meaning that someone may have a flashback of the COBOL days in trying to hunt down a missing punctuation.

With that said, when instantiating business objects, you have to supply the required properties to the object, even though default values are already specified. Identities are an exception because this is a different construct, and LINQ to SQL handles this accordingly. However, if you use GUID's with your tables as the primary key, you have to call Guid.NewGuid() manually to create an ID.

Listing 5

order.OrderKey = Guid.NewGuid();
order.CreatedDate = DateTime.Now;

In a sense, this is better than using an integer identity value because the primary key value is immediately known, and it is not as necessary to call the context's SubmitChanges() method right away.