I'm working with the new Beta 2 of VS2008 and LINQ is really great but i'm
searching for an opposite construct of the SubmitChanges() method to discard
changes. Background:
I have a form for editing a single data row and only if the user clicks the
OK button the changes are saved into the DB. That's no problem to call the
SubmitChanges() method on the DataContext. Otherwise the last saved state
should be restored. An DiscardChanges() method on the DataContext would be
nice, because LINQ tracks the changes made on the objects so not submit the
chages isn't the solution or have I overseen something?

Thanks.

Re: LINQ to SQL: Opposite of SubmitChanges() by Cowboy

Cowboy
Tue Jul 31 09:47:29 CDT 2007

Now that I have finished the book, I need to get back into LINQ (et al), so
I am answering a bit in the dark when I state this. But, the norm, in MS
client data bits, is to keep both the original state and the current state.
The original state is overwritten only when data is saved. This is the way
with XSD (strongly typed datasets) and how I thought LINQ was working. If
so, rollback to a previous state. If not, you will have to refill the
original state of the object when you make the trip to the server.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
http://gregorybeamer.spaces.live.com
Co-author: Microsoft Expression Web Bible (upcoming)

************************************************
Think outside the box!
************************************************
"Ralf Ehlert" <RalfEhlert@discussions.microsoft.com> wrote in message
news:5B9EA71B-5068-45D4-BB9E-0E3593586D87@microsoft.com...
> I'm working with the new Beta 2 of VS2008 and LINQ is really great but i'm
> searching for an opposite construct of the SubmitChanges() method to
> discard
> changes. Background:
> I have a form for editing a single data row and only if the user clicks
> the
> OK button the changes are saved into the DB. That's no problem to call the
> SubmitChanges() method on the DataContext. Otherwise the last saved state
> should be restored. An DiscardChanges() method on the DataContext would be
> nice, because LINQ tracks the changes made on the objects so not submit
> the
> chages isn't the solution or have I overseen something?
>
> Thanks.



Re: LINQ to SQL: Opposite of SubmitChanges() by RalfEhlert

RalfEhlert
Tue Jul 31 13:58:01 CDT 2007

I have found the method GetOriginalEntityState() on the Table class. That's
not exactly what I search but should be useful too.

"Cowboy (Gregory A. Beamer)" wrote:

> Now that I have finished the book, I need to get back into LINQ (et al), so
> I am answering a bit in the dark when I state this. But, the norm, in MS
> client data bits, is to keep both the original state and the current state.
> The original state is overwritten only when data is saved. This is the way
> with XSD (strongly typed datasets) and how I thought LINQ was working. If
> so, rollback to a previous state. If not, you will have to refill the
> original state of the object when you make the trip to the server.
>
> --
> Gregory A. Beamer
> MVP; MCP: +I, SE, SD, DBA
> http://gregorybeamer.spaces.live.com
> Co-author: Microsoft Expression Web Bible (upcoming)
>
> ************************************************
> Think outside the box!
> ************************************************
> "Ralf Ehlert" <RalfEhlert@discussions.microsoft.com> wrote in message
> news:5B9EA71B-5068-45D4-BB9E-0E3593586D87@microsoft.com...
> > I'm working with the new Beta 2 of VS2008 and LINQ is really great but i'm
> > searching for an opposite construct of the SubmitChanges() method to
> > discard
> > changes. Background:
> > I have a form for editing a single data row and only if the user clicks
> > the
> > OK button the changes are saved into the DB. That's no problem to call the
> > SubmitChanges() method on the DataContext. Otherwise the last saved state
> > should be restored. An DiscardChanges() method on the DataContext would be
> > nice, because LINQ tracks the changes made on the objects so not submit
> > the
> > chages isn't the solution or have I overseen something?
> >
> > Thanks.
>
>
>