Paul Brown

The Attach method allows updating with a disconnected object that has been updated. The easiest version to use is: Public Sub UpdateCustomer(updatedCustomer As Customer)    Dim dc As New MyDataContext()    dc.Customers.Attach(updatedCustomer, True)    dc.SubmitChanges End Sub The only problem is that this generates a SQL statement that updates all columns rather than just the on that has changed. In other words, we used a little extra bandwidth. The reason this happens is because when we disconnected the object, we lost all the built in change tracking provided by LINQ (for now). Option 2 is to get a new copy of the object and update it. Public Sub UpdateCustomer(updatedCustomer as customer)   Dim dc as New MyDataContext   Dim originalCustomer as Customer = from c in     dc.Customers Where c.PrimaryKey =     updatedCustomer.PrimaryKey   originalCustomer.CustomerName =     updatedCustomer.CustomerName   originalCustomer.CustomerAddress =

Visual Studio doesn't seem to like SPAN tags. I've already reported a bug where it adds duplicates SPAN tags to templated fields in a GridView or DetailsView that is within a span tags. Now, it's moving my span tags around. I had two span tags to define left and right columns with inline-block. They were contained within the same div. Somehow, VS decided that the left span belonged to the div above and moved it all on it's own. If it keeps happening, I'll see if I can narrow the circumstances down and get a bug report filed. Technorati Tags: Visual Studio 2008 , SPAN , Designer

Found an annoying bug in VS today. If you have a GridView contained in a Span tag on a ContentPage and edit the fields, VS will add span tags around the fields you change. Of course, when your done making your changes and click OK, you'll get a rendering error. Simply edit the source and remove the spurious span tags. Technorati Tags: GridView , Visual Studio 2008 , Span , ContentPage , MasterPage

Technorati Tags: LINQ To SQL I spent half an hour tracking this down today and couldn't find it based a google search of the blog title. So.....If your OnValidate code isn't firing in your LINQ to SQL, your probably working with an out-of-date signature. Somewhere between Beta 2 and RTM, they snuck in a slight change by adding a parameter to indicate what kicked off the method. Make your signature similar to: Private Sub OnValidate(ByVal action as ChangeAction) The ChangeAction enumeration values are Insert, Update, Delete and None. So if you need special code for the insert versus the update, you can code an IF statement appropriately. You can find all of the breaking changes here .

They just have gotten so arrogant. They're good but I don't they're that good. They did beat some good teams but usually when those teams were struggling (SD in particular). I might feel differently if they were a little humble about it. On the other hand, I'd love to Favre get another ring. He's been a great player and stayed with the team/town that made him. Can he beat NE? If they played in the frozen tundra, definitely yes. Neutral field, maybe.

Played around with the LDS and can really only see using the LDS for really thin apps where you don't want a lot of structure (maintenance tools, prototypes, etc.) Of course, this is the same time I get my Visual Studio magazine and it covers the topic very well. Read Roger Jennings article on what's missing in VS 2008, the LINQ to SQL section talks about this issue in depth. Meanwhile, I found this great blog from Rick Strahl on returning IQueryable that will do a lot of what I want and still get the benefit of only pulling back what I want.

In playing with LTS I keep coming back to the question "Should the DataContext be exposed to the presentation so that you can use the LinqDataSource?" Does this violate the separation of layers by moving business (domain) logic into the presentation tier? Dinesh and Scott Guthrie seem to advocate exposure but I could be interpreting them wrong. On the flip side, Rick Strahl posted some stuff that would seem to say no. Note: I do see that he is more concerned with a disconnected state than with the datacontext). My current thoughts are that this is a six of one/half dozen issue. Seems like I get the business rules (validation, etc) I want separated from the data. Should be maintainable. So for now, I'm going to use it on some legacy applications that are well defined where this would be a definite time saver. We'll see....