.Net 3.5 had some nice tricks in it. LINQ-to-XML was one of them. With the new "X"-types, you can make working with XML really easy.

VB.Net 9 takes it one step further, and lets you write XML in your code without strings.

"Hey Rich, that’s old news," I hear you say. "And who’s interested in VB today anyway?"

Well, apparently there are a lot of VB-er’s still out there. I am mainly a C# developer myself, but I found that VB was perfect for a problem I had recently -  loading of XML data into a SQL Server table.

SQL Server 2005 and XML Fields

I recently came across the need to load a database with XML data fields in SQL Server 2005. I had a series of XML documents which all needed to be pumped into a table containing a field of type XML. I could have opened up SQL Server Management Studio and fired in a load of strings, but I was a bit concerned that the XML might not be formatted quite correctly, which would have caused problems in the loading process.

Another problem was that I wanted to be able to add dynamic XML. I wanted to generate some XML data on the fly. That’s not so easy with insert statements in SQL.

LINQ-to-SQL and XML Fields

Using my recently-acquired LINQ-to-SQL knowledge, I knew that the Entities generated for an XML field are translated to XElements – the new XML type in .Net 3.5. I also knew that VB 9 lets you create an XElement by using XML in code itself:

So I came up with a plan…

Inserts with LINQ-to-SQL

For data-loading, LINQ-to-SQL is magic. A simple Insert is a piece of cake.

First, create your DataContext using the Visual Studio template, then drag the table you are inserting to onto the DataContext canvas. That gives you an Entity class. You then can create an Entity in your code, call InsertOnSubmit on the DataContext table, then call SubmitChanges on the DataContext itself.

Using Object Property Initializers, you can make this really easy.

Here’s what it looks like with VB.Net using an XML datatype:

(Sorry to have torn the edge off the code there, but it wouldn’t fit nicely in my post at full width. XML can be a little long sometimes.)

The great thing here is that any malformed XML is highlighted (or even automatically corrected) for me by the VB compiler. I can also add parameters and generate lots of different XML using the familiar ASP syntax:

It’s all super-easy, and takes about 1 minute to get started.

I just read a fantastic quote about LINQ from the book Pro LINQ: Language Integrated Query in C# 2008 by Joseph C. Rattz, Jr.:

I prefer to think of LINQ as a data iteration engine, but perhaps Microsoft didn’t want a technology named DIE.

I think they already built the technology for such a product, and put it in Vista.

It’s a great book. The first LINQ book I’ve found with a really detailed explanation of LINQ-to-SQL and the SQLMetal generation tool.

One of my favorite bloggers is Matt Berseth. Nearly once a week he comes up with a post where he does something amazing with the standard ASP.Net controls. I usually read his posts in awe. He’s really good.

But he’s not only is a good developer, he’s a great writer. Even though his posts are concise and straight to the point, most of them are pages long. You can really learn a lot from following his instructions.

He’s so good, in fact, that he regularly gets a mention on Scott Guthrie’s posts.

One of my favorite posts of his was where he used LINQ-to-SQL, a LinqDataSource control, and an ASP.Net ListView control – all new in .Net 3.5 – and made a grid with grouping functionality. He did it all in a standard way, and didn’t use any funny tricks.

Here’s a link to the article:

Building a Grouping Grid with the ASP.NET 3.5 LinqDataSource and ListView Controls

Enjoy!

Yesterday I thought I’d learn about the LinqDataSource in ASP.Net 3.5, and got an interesting surprise.

The new LinqDataSource can also be used with a LINQ-to-SQL model to perform updates. You simply add the DataSource to your page, set the table name, and set EnableUpdate to true. Then, using a standard DataControl, you can make updates to your data entities.

The question is, how does this work? It appears to be a bit magical.

The Magic of LINQ

In a previous post, I mentioned that LINQ-to-SQL updates can be done in two ways: either you make a call to retrieve a row, then update it, or you provide known values for all fields and try to update using optimistic concurrency.

If the LinqDataSource used the first technique, the performance might be bad. Plus, it would have to only update those fields that had been updated by the DataControl, and ignore the rest. That wouldn’t make sense, so I correctly supposed that was not what was happening.

It makes more sense that the LinqDataSource would use the values input by the user to make the changes. It could use optimistic concurrency to compare all the entered values.

The problem is, I don’t always display all fields from a particular row on the form, so how would the LinqDataSource know what the missing fields were. Remember, all the fields involved in the update are required for the optimistic concurrency to work. That is usually all the fields in a row, and they aren’t usually all displayed.

So, have a guess. Where does the LinqDataSource store it’s values?

Let’s think now. Where would be the easiest place to keep it? To keep it really simple, I’ll let you ignore all other aspects of building an application, like security or performance.

Yep, you guessed it – ViewState.

The ViewState actually contains all values for all the fields in a LINQ-to-SQL entity by default. Those values are sent to the client, even if the user isn’t supposed to be able to see them.

Aaaarrgghhhh!

Now, let’s not get overexcited. The ViewState is encoded, so it’s not easy to just go and change it. But it’s not impossible. In general, I don’t think it’s such a great idea to have all data sent to a client by default. Someone is going to overlook something one day, and there’ll be a costly mistake.

And what if you display a large grid using the LinqDataSource. Well, you aren’t just getting the ViewState from the grid sent back and forth with your page, but the LinqDataSource is going to store all your data retrieved in the ViewState too.

Bummer!

Great control. Large overhead.

Kicking out the ViewState

The good news is that the ASP.Net team realized that this was a problem and did something about it.

If you look carefully, you will notice that the LinqDataSource has a property StoreOriginalValuesInViewState. By default (sigh) that property is set to true. If you set it to false, the control won’t work any more. Simple as that.

Here’s what the official documentation has to say about that:

If you set the StoreOriginalValuesInViewState property to false, the original values are not persisted in view state for the data-bound control. In that case, LINQ to SQL cannot verify the integrity of the data. LINQ to SQL will throw an exception that indicates a data conflict even if the data in the data source has not actually changed.

That’s in the remarks section of the LinqDataSource.StoreOriginalValuesInViewState property documentation.

Funnily enough, the same section states the problem with stuffing data into the ViewState:

Storing the original values in view state can cause the page size to become unnecessarily large and can expose sensitive data to a malicious user.

Now, I don’t know about you, but that looks like a pretty serious warning to me. Why isn’t it in a more obvious place, like as a comment that pops in up Intellisense whenever you use a LinqDataSource?

Check the UpdateCheck

So how do you handle it? How can you use the LinqDataSource?

The answer lies in the generation of the LINQ-to-SQL model which you generate. Each entity field has a Column attribute which allows you to specify if it is used for checking during an optimistic concurrency field comparison.

For example, you could create a Model with the following Property:

[Column(Storage="_AddressID", UpdateCheck=UpdateCheck.Never, ...
public int AddressID
...

Notice the UpdateCheck.Never value. That means that the field will not be used in the optimistic concurrency check.

The documentation helps a little again:

By default, when update and delete operations have been enabled, the LinqDataSource control stores the original values for all the records in view state. The LinqDataSource control stores values for all primary keys and all properties not marked with UpdateCheck.Never in the Column attribute. You set the UpdateCheck property of the Column attribute in the O/R Designer.

Admittedly, I haven’t yet tried that, so I don’t really know how if you can change that setting for a field without changing generated code, which would be a big no-no. I’ll just have to get back to you on that.

Stamp In, Please

However, there is a shortcut trick.

Basically, if you add a field of type timestamp to your record, only that field will be used for the concurrency check, and only that field’s data will be stored in the ViewState.

If the underlying data source contains a timestamp field that is automatically updated during an update, you can store only that value in view state. In that case, the timestamp property in the entity class is set to IsVersion=true and all the properties are set to UpdateCheck.Never. Because a timestamp field is automatically updated by the database every time that data in that record changes, LINQ to SQL determines from that value if data has changed. This helps reduce the size of view state, and no sensitive data is exposed. LINQ to SQL will check for data consistency by comparing the timestamp value in view state with the timestamp value in the database.

The documentation is great, if you know where to find it.

Conclusion

So, the answer is, if you use the LinqDataSource to throw a quick application together, make sure you use a timestamp field in your table. Call it UpdatedOn, or something. It will make the use of the LinqDataSource a lot easier, if only because you’ll sleep better not worrying about it.

When learning LINQ-to-SQL, it’s not immediately obvious how to do an update. Querying is easy, and there are methods for inserting and deleting. Updating usually occurs by modifying an object already known to the DataContext and then calling SubmitChanges on the context.

var product = (from p in dataContext.Products
               where p.ProductID == 1
               select p).Single();

product.Name = "Richard's product";

dataContext.SubmitChanges();

It’s nice to see that MSDN documentation actually addresses the obvious arising question:

Q. Can I update table data without first querying the database?

A. Although LINQ to SQL does not have set-based update commands, you can use either of the following techniques to update without first querying:

• Use ExecuteCommand to send SQL code.
• Create a new instance of the object and initialize all the current values (fields) that affect the update. Then attach the object to the DataContext by using Attach and modify the field you want to change.

If you ask me, using an ExecuteCommand defeats the object of LINQ-to-SQL. After all, we’re using it as a data-access-layer to generate entities in code based on the data schema. The last thing we want to have to do is start writing strings of SQL.

So that’s out.

I’m So Attached

The second option is to use the Attach method on the table we’re updating. I’ve tried to use the Attach method before, but it didn’t work.

To see what I mean, try this in LINQPad (using the AdventureWorks database from CodePlex):

var product = new Product();
product.ProductID = 1;
product.Name = "Richard's product";

Products.Attach(product);

var changeSet = GetChangeSet();

changeSet.Dump();

You’ll see that there are no changes to make, so no updates are made.

Now, move the line of code that does the update after the call to Attach, so as to attach the product first before updating the field:

var product = new Product();
product.ProductID = 1;

Products.Attach(product);

//Notice we're doing this laterproduct.Name = "Richard's product";

var changeSet = GetChangeSet();

changeSet.Dump();

The changeset now shows that one update is ready to be made. Unfortunately, if you call SubmitChanges, you get an exception:

SqlDateTime overflow. Must be between 1/1/1753 12:00:00 AM and 12/31/9999 11:59:59 PM.

The MSDN documentation isn’t so clear here. What do we need to set to get it to work?

The SQL being sent to the database is instructive:

UPDATE [Production].[Product]
SET [Name] = @p9
WHERE ([ProductID] = @p0) AND ([Name] IS NULL)
AND ([ProductNumber] IS NULL)
AND (NOT ([MakeFlag] = 1))
AND (NOT ([FinishedGoodsFlag] = 1))
AND ([Color] IS NULL)
AND ([SafetyStockLevel] = @p1)
AND ([ReorderPoint] = @p2)
AND ([StandardCost] = @p3)
AND ([ListPrice] = @p4)
AND ([Size] IS NULL)
AND ([SizeUnitMeasureCode] IS NULL)
AND ([WeightUnitMeasureCode] IS NULL)
AND ([Weight] IS NULL)
AND ([DaysToManufacture] = @p5)
AND ([ProductLine] IS NULL)
AND ([Class] IS NULL)
AND ([Style] IS NULL)
AND ([ProductSubcategoryID] IS NULL)
AND ([ProductModelID] IS NULL)
AND ([SellStartDate] = @p6)
AND ([SellEndDate] IS NULL)
AND ([DiscontinuedDate] IS NULL)
AND ([rowguid] = @p7)
AND ([ModifiedDate] = @p8)
-- @p0: Input Int (Size = 0; Prec = 0; Scale = 0) [1]
-- @p1: Input SmallInt (Size = 0; Prec = 0; Scale = 0) [0]
-- @p2: Input SmallInt (Size = 0; Prec = 0; Scale = 0) [0]
-- @p3: Input Decimal (Size = 0; Prec = 29; Scale = 4) [0]
-- @p4: Input Decimal (Size = 0; Prec = 29; Scale = 4) [0]
-- @p5: Input Int (Size = 0; Prec = 0; Scale = 0) [0]

The problem is now that LINQ-to-SQL tables automatically use optimistic concurrency, and for some reason (maybe only in LINQPad) the SellStartDate is not set, and neither are the rowguid or ModifiedDate fields. In any case, either we have to turn off optimistic concurrency, or set all the field values ourselves.

Using Optimistic Concurrency with Updates

Unfortunately, by default all fields are used for optimistic concurrency, so you have to set values for all fields. If you were using ASP.Net you could keep a copy of the variables in the session state or something, but at least it saves you a round trip to the database.

Here’s the code that actually does perform an update:

var product = new Product();
product.ProductID = 1;
product.Name = "Adjustable Race";
product.ProductNumber = "AR-5381";
product.MakeFlag = false;
product.FinishedGoodsFlag = false;
product.Color = null;
product.SafetyStockLevel = 1000;
product.ReorderPoint = 750;
product.StandardCost = 0.0000M;
product.ListPrice = 0.0000M;
product.Size = null;
product.SizeUnitMeasureCode = null;
product.WeightUnitMeasureCode = null;
product.Weight = null;
product.DaysToManufacture = 0;
product.ProductLine = null;
product.Class = null;
product.Style = null;
product.ProductSubcategoryID = null;
product.ProductModelID = null;
product.SellStartDate = DateTime.Parse("6/1/1998 12:00:00 AM");
product.SellEndDate = null;
product.DiscontinuedDate = null;
product.Rowguid = new Guid("694215b7-08f7-4c0d-acb1-d734ba44c0c8");
product.ModifiedDate = DateTime.Parse("3/11/2004 10:01:36.827 AM");

Products.Attach(product);

// Make the change here
product.Name = "Richard's product";

SubmitChanges();

So you can avoid two trips to the database by doing the update manually and using the Attach method on the table you are updating.

Mind you, I’m not sure that’s worth it.

If you want to know more about updating LINQ-to-SQL objects with the DataContext, I recommend Pro LINQ: Language Integrated Query in C# 2008. It’s got 6 chapters just about LINQ-to-SQL, the DataContext, and concurrency issues.

P.S. In case you’re interested, I generated some of that code in LINQPad using the following code (it doesn’t work for dates or Guids, before anyone complains):

var product = (from p inProducts

wherep.ProductID == 1

selectp).Single();

var fields = from field inproduct.GetType().GetFields()

select new{

Name = field.Name,

Value = field.GetValue(product),

TypeName = field.FieldType.Name };

foreach (var field infields)

Console.WriteLine("product.{0} = {1};", field.Name,

field.TypeName == "String"? "\""+

field.Value + "\"":

field.Value ?? "null");

Quick tip: If you want to see the SQL generated by LINQ to SQL for a query or command, simply set the Log property of your generated DataContext class to an instance of a TextReader.

If this is your code:

using System;
using System.Linq;
using System.Data.Linq;

namespace LINQtoSQLConsole {
  class Program {
    static void Main(string[] args) {

      var db = new NorthwindDataContext();

      // Use the console to see the SQL
      db.Log = Console.Out;

      // A query
      var cust = db.Customers.Single(
                    c => c.CustomerID == "ALFKI");

      // An update
      cust.Region = "Northwest";
      db.SubmitChanges();
    }
  }
}

… then this is what you’ll see:

Pretty good, eh?