There is no comparison between the two. Linq to SQL is for, well, SQL. Linq to Entities can be used for a variety of objects. DeleteAllOnSubmit would not make since for this because the entities could be from any type of collection; a list of strings, a list of WMI objects, etc. where delete has no meaning, or a very different one. I know the language. I've read a book. - _Madmatt

Got a work around, did something like this Guid ReqID = new Guid(Request\["ReqID"\]); var req = dbContext.Requisitions.First(r => r.ID == ReqID);

Yes, That's the way. Thanks for sharing solution. Swiftain wrote: "OnRowCreated" ain't firing Will try to solve it as getting enough time. :) Regards, Hiren. My Recent Article: - Way to know which control have raised PostBack My Recent Tip/Trick: - Remove HTML Tag, get plain Text

There are a couple of very valid reasons for Marks reply to you. The most important reason is that it becomes very difficult to track answers if multiple threads are spawned about the same topic. Bear in mind that the question may be viewed, in the future, by others who want to know the answer to the problem; the search engines will point them to one thread. Churn and growth of other threads could mean that they end up not seeing the whole picture because the vital part of the answer is now in another thread. Now, take a deep breath and relax. I have CDO, it's OCD with the letters in the right order; just as they ruddy well should be Forgive your enemies - it messes with their heads My blog | My articles | MoXAML PowerToys | Onyx

First of all don't store it in session state. Remember this is the result of your query, not the query itself, and could be very large. It's also quite clear how to cast it. It is being passed into your method as an IEnumerable, guess what it should be cast as? I know the language. I've read a book. - _Madmatt