Comments on Brian Orrell: LINQ to SQL Updating in ASP.NET - The Right Way

Brian, This is a great article and would really l...

2009-10-29T13:56:35.699-05:00

Brian,

This is a great article and would really like to test it out, however, the source code download link you provided seems to be broken. Any chance you can revive it?

Thanks!
Justin

Sam, the key thing is overriding the SaveViewState...

2009-04-17T10:56:52.590-05:00

Sam, the key thing is overriding the SaveViewState and LoadViewState methods in your pages, otherwise, the serialization will fail.

Brian, what trick did you use to get the addresse...

2009-04-10T20:36:04.179-05:00

Brian, what trick did you use to get the addresses of the customer to serialize?
I downloaded your project, added my own context and a test page and I can serialize child entities for my tables in your project.
I copied your SerializerUtil class to my project, set the serialization mode of my context to unidirectional but I cant get child entites to serialize.
My project and yours point to the same database.
I verified that I am getting child entities back from my initial select.
Thanks,

Sam

Thanks Sam. :) You have to take the hit somewhere...

2009-04-10T16:23:43.081-05:00

Thanks Sam. :) You have to take the hit somewhere like you said (ViewState, Session, etc...) but many times, it is worth it for the user experience.

As more client friendly means of holding on to state become mainstream (Silverlight, Flex, etc...) the "hit" will be less painful.

You said ....this article also addresses the need ...

2009-04-10T16:20:37.630-05:00

You said ....this article also addresses the need to add multiple children (all at once) rather than requiring the parent be saved first before children can be added. You have to use some form of temporary storage (whether Viewstate, Session, etc...) to maintain state while you are adding multiple children to a parent.

Brian I think you and I are the only two coders on the planet who actually do this. Let's not tell Microsoft it's a great way to create a friendly UI where the user can cancel out of changes.

Great article, thanks for sharing.

Be careful when using session variables to persist...

2009-02-16T18:48:43.468-06:00

Be careful when using session variables to persist the data (the same session variable which is what I was doing). If the user opens multiple windows they will be walking all over each other. For ex. if I load Bob's profile into session and then Jim's profile in a sep window - the session variable is for Jim's. So if I save Bob's profile it will use Jim's profile data and write to the db (OOOPS).

Is there some reason why you can't just call a sto...

2009-02-15T11:45:26.014-06:00

Is there some reason why you can't just call a stored proc and let a DBA manage performance?

ViewState does not have to be stored in the page. ...

2008-11-17T10:51:39.068-06:00

ViewState does not have to be stored in the page. There are many great examples out there of storing viewstate server-side only.

The primary difference between ViewState and Session is the ability for state to be saved on a per-page basis which has its merits for the scenario described in the article.

Totally agree that ViewState can become unwieldy and overly heavy from a network load perspective (if used the way it is setup out of the box).

The point of the article is less about how to persist but rather how to rehyrdrate persisted objects for sending back to a services "tier". LINQ to SQL missed the mark on making this scenario as straightforward as it could be.

Why in the world are you using the ViewState? As ...

2008-09-25T13:50:23.263-05:00

Why in the world are you using the ViewState? As one commenter mentioned, you are sending this information to the browser and back. Not only does that effectively send the information twice, but it could end up sending information that you do not want available. It also increases the size of the content stream that must be delivered to the client.

It does seem like storing the object and reattaching it is the proper mechanism and is definetly helpful for pointing that out.

But it would seem that using the Session as the storage mechanism would be much more appropriate. That way the object is solely on the server side.

This is even more true if you want to use Ajax (whether you use ASP Ajax, YUI, jQuery, etc.) or Silverlight, etc. to do form submissions.

Updated now. Thanks.

2008-08-31T22:25:08.645-05:00

Updated now. Thanks.

Thank you Brian. Could you update the link for sou...

2008-08-31T20:26:36.657-05:00

Thank you Brian. Could you update the link for source code.

This was a very helpful article, as I encountered ...

2008-07-29T10:01:26.861-05:00

This was a very helpful article, as I encountered the same issue. It would be cool if there was a way to set the concurrency mode, as there are times when you really do want it to commit the data is it is presented, and yes, the source may have been changed by something else during the process.

In any event, I was able to resolve the issue by using stored procedures for the Insert and Update actions, then mapping the Insert and Update actions to those stored procedures in the LINQ to SQL dbml designer. Still not terribly pretty, but I do know what its doing now :) .

Hi Brian,Thanks for a very good article. I think I...

2008-07-25T16:27:49.461-05:00

Hi Brian,

Thanks for a very good article. I think I understand both your main points (about the boolean values that need to be set to their original values before the Attach and about your approach to store the original object and use it for the Attach).

However I'm not 100% sure about the timestamp. If I use your technique of storing the original object (and using it for the attach during the Save event), do I still need a timestamp? Doesn't seem that way to me but I may be overlooking something...

PS to the group: I don't think newbie's solution of re-reading the db during the Save event will apply in a scenario where you want to load the original data from the db in the OnLoad event of an "Edit" page and then "watch for changes" while the Edit page is displayed to the user (i.e. if you want to use LINQ's optimistic concurrrency to find out whether the underlying data has changed since the user started editing the data on the form/page up to the point where the user clicks Save). In such a case I think Brian's proposed approach of storing the original object would work like a charm.

Louis

Definitely agree on the ViewState vs. the re-looku...

2008-07-21T05:23:24.109-05:00

Definitely agree on the ViewState vs. the re-lookup. For a basic update, it would make more sense to a do a re-select before updating rather than storing the original in viewstate.

However, this article also addresses the need to add multiple children (all at once) rather than requiring the parent be saved first before children can be added. You have to use some form of temporary storage (whether Viewstate, Session, etc...) to maintain state while you are adding multiple children to a parent.

Good points. We are all struggling with the "right" way to do this stuff and I'm sure we'll all be wrong in the long run. :)

So you would rather push the data via viewstate to...

2008-07-17T18:03:01.380-05:00

So you would rather push the data via viewstate to the client browser, then have then client browser push it all the way back to you vs:

1) Hit the db w/the *same context* for reinitialize
2) Update multiple cols (DB pages/extents come into play for the update but the overhead at that point is the lookup)

Unless its a row with a ridiculous amount of cols I bet the serialize|deserialize is worse than the DB round trip for a single read (based on PK lookup). Kudos to the newbie on that one

Tim, unfortunately that is not the case. Read the...

2008-07-14T06:27:31.419-05:00

Tim, unfortunately that is not the case. Read the post and you'll see why. The rowversion property will not help you there. The easiest way to see the problem is with boolean values. If you are setting a value to false that was originally true, the datacontext will not register a change unless you set the value of the boolean value (to true) PRIOR to setting it to false after being attached.

Row versions are for optimistic concurrency checking ONLY. This is an issue I have confirmed with Microsoft, it's not solved with your solution.

Your solution is over engineer. According to MSDN ...

2008-07-11T19:10:06.532-05:00

Your solution is over engineer. According to MSDN article on the Attach method "the entity is assumed to be in its original value state. After calling this method, you can then update its fields, for example with additional data sent from the client."

Therefore, a better way to update data from an ASP.NET web page is

DataContext db = new DataContext();

Customer c = new Customer();
c.CustId = paramCustId
c.Version = ViewStateVersion
db.Customers.Attach(c);
c.comment = "some comments";
db.SubmitChanges();

// Store the row version in view state.
ViewStateVersion = c.Version;

The trick is to assign the customer entity with the original rowversion before attached it to the dataContext

Oops scratch that... it was a totally unrelated pr...

2008-06-08T18:05:02.322-05:00

Oops scratch that... it was a totally unrelated problem :)

It fails with an exception or it appears successfu...

2008-06-08T17:48:40.879-05:00

It fails with an exception or it appears successful but doesn't update the value. Are you using a timestamp column?

What is Data.DC-- you should NEVER hold onto a datacontext. It should be used and then disposed-- similar to a database connection.

Do not cache your datacontext in a middle tier static or some such thing. That is not the right approach.

Have a look at my latest post on using a service tier if you want to have a separated business tier for updates.

There must be a better way to do this.It's not eve...

2008-06-08T17:44:11.910-05:00

There must be a better way to do this.

It's not even anything to do with ASP.NET or Attach -- even if I do the same thing entirely in code by just updating a value, it'll refuse to update when the value is set to false.

Am I missing something?

This fails:

Invoice inv = Data.DC.Invoices.Single(x => x.Id == id);
inv.IsActive = false; //works only when setting to true
Data.DC.SubmitChanges();

Responding to anonymous post on April 7:You can us...

2008-05-28T18:20:14.915-05:00

Responding to anonymous post on April 7:

You can use iqueryable to access a property such as Product.ProductName in an Eval.

http://forums.asp.net/p/1262668/2377732.aspx#2377732

-pugs421

I've been searching for a simple yet functional ex...

2008-04-14T07:41:24.763-05:00

I've been searching for a simple yet functional example of updating a row using LINQ to SQL from ASP.Net for a few days now, but yours is the only one that really makes sense to me.

Thanks a lot for the info.

This is exactly the reason I would use a standard ...

2008-04-07T14:40:19.661-05:00

This is exactly the reason I would use a standard form and not use the DetailsView or FormView. They are deceptively simple and then when you have a situation like you have with a foreign key lookup they take more time than if you used the method I outline in my post. It's really not hard at all to do on your own with custom code.

First off, Details view controls (and form view co...

2008-04-07T14:33:13.278-05:00

First off, Details view controls (and form view controls for that matter) are pure evil. I have seen nothing but trouble from them.

Be sure you are using a SQL Server 2005 Timestamp column, not a datetime field that you set as a timestamp. I couldn't tell from your post which you were using. Also, be sure you set your DataKeyNames property correctly in your data source control.

I am using a TimeStamp field on SQL Server 05 and I have my gridView's DataKeyName set to the PK of the table it is pulling from.

Now that I've played around with it more I realize my problem is that I'm using a custom SELECTING statement for my LinqDataSource's SELECTING event.

The reason for this is because for some reason the gridView won't display a field in a FK linked table (I have something like ProductID in my detailsView and I want to use the EVAL statment to display ProductName via Product.ProductName instead of just ProductID however, that always displays a blank field so I wrote a custom LINQ Selecting statement instead to just return the ProductName as part of the SELECT statement and display that in the detailsView).
So if I do NOT use the Selecting Event the update works fine now that I’ve added the TimeStamp field (thank you for that in your post).
But I’m still out of luck on how to do the update when I’m using the custom SELECTING LINQ statement (I really just wish my EVAL statement would work… but nothing is returned from that either…)
It is all most perplexing sadly…
Thank you again for your help (If you have any suggestions on how to solve this quandary I’d appreciate it greatly!)

First off, Details view controls (and form view co...

2008-04-07T14:22:23.030-05:00