I have been investigating LINQ to SQL supposed ability to handle disconnected entities. For example, grab a single entity with a data context, dispose of the data context and viola you now have a disconnected entity. By default, you can access properties of that entity that are not other entities themselves. If you try you will get a data context disposed exception. 

LINQ to SQL has a handy method called Attach which is supposed to re-attach entities so you can send changes to the database.  When I called the Attach method I would get the exception:

An attempt has been made to Attach or Add an entity that is not new, perhaps having been loaded from another DataContext. This is not supported.

This seemed to be an issue with entities that had relations to other entities.

Inside the data context that was used to select data, if I set DeferredLoadingEnabled = false I was able to attach OK (specifying true for the asModified parameter). This meant that all related entites were also retrieved but it made the update code a lot simplier.

I was making some changes to a client's website recently and found static repeated HTML in quite a few places. Their internal developer had put something together than ended up going live!

I decided to create put the HTML in a SQL DB and use LINQ to SQL to retieve the content on demand. All ready to go live and website being hosted somewhere else on their network with slow access to their DB server. No problem, export the content as XML and use LINQ to XML to retrieve.

I ended up getting the content data into a DataTable with a table name of "Content" and then calling the data table's WriteXML method to output as XML. The format was:

<?xml version="1.0" standalone="yes"?>
<DocumentElement>
  <Content>
    <PageName>HOME</PageName>
    <Text>blah</Text>
  </Content>
</DocumentElement>

Then you can write a function that contains your LINQ to XML:

Very cool! And much easier that typed data sets.

Got stuck into LINQ to XML the other week and I thought wouldn't it be great if this could be strongly typed somehow. Of course the MS XML Team were WAY ahead of me. You can find the article at their blog here.

It's only in preview Alpha 0.2 Refresh at this stage (here) so I'm a little hesitatent to install on my regular machine. What the heck, if you're not living on the edge, you're taking up too much room. Right?

Scott Hanselman also has some interesting thoughts on LINQ to Everything.

LINQ for us was a huge productivity improvement as we didn't have to generate stored procedures anymore for our CRUD database operations. Because we had a rule that ALL data access was via stored procedures, everytime we had a new processing operation or new search situation, we either had to adapt an exisitng stored procedure or create a new one. Then we had to create a method in our data layer to make the call to the stored procedure.

Now with LINQ we can create a new method in our data layer. Saves time and the generated SQL is not too bad. One thing going against LINQ is that it's very easy to start putting LINQ queries in your UI (aka inline SQL from the old days).

Learning LINQ is a challenge. More specifically doing things that come naturally in TSQL are challenging. I have found it quicker to create a few stored procedures to do some complex queries and call them through the data context.

Never fear LINQPad is here. Very similar to management studio you can connect to servers, run queries against databases. I have found it to be a great tool for learning LINQ.

Happy LINQing.