tags:

views:

53

answers:

2

I have a standard update happening via linq to sql but the data does not persist to the database.

I am using an auto-generated class via the .dbml file designer.

The update statement is below:

public static void UpdateEmailsInWorkingTable(Guid emailGuid, string modifiedEmail)
{
        using (EmailDBDataContext DBContext = new EmailDBDataContext())
        {
            EmailAddress_Update EAUpdated = (from e in DBContext.EmailAddress_Updates
                                             where e.EmailGuid == emailGuid
                                             select e).SingleOrDefault();

            EAUpdated.EmailAddress = modifiedEmail;
            EAUpdated.IsValid = 'Y';
            EAUpdated.UpdateFlag = true;
            EAUpdated.LastChangedDtTm = DateTime.Now;
            try
            {
                DBContext.SubmitChanges(ConflictMode.FailOnFirstConflict);
            }
            catch (ChangeConflictException ex)
            {
                // do stuff here
            }
        } 
}

I looked through my auto-generated DataContext class and the only glaring difference is that the table in question EmailAddress_Update does not implement the two interfaces INotifyPropertyChanging and INotifyPropertyChanged that the other auto-generated entities do.

I am assuming that this is the cause of why the changes are not being persisted is it not???

To put it simply none of the Extensibility Method Definitions get generated for any part of this one class. If this is the cause of my problems, what in the database would be causing this to not auto-generate properly??

Thanks~

+1  A: 

I posted this question on MSDN as well here: MSDN Linq to Sql if you wanted to see the replies. But I found part of the reason why the code doesn't generate.

Here is a piece from my MSDN response:

I created a small test table without a primary key and added it to the designer and sure enough it didn't generate any of the Extensibility methods for that instance.

So I then added a primary key to the same table and re-added it to the designer and sure enough all of the extensibility methods and change tracking events were generated.

My question now is why must there be a primary key for this stuff to auto-generate?

Ben Ziegler
A: 

Ok so to answer my own question "My question now is why must there be a primary key for this stuff to auto-generate?" I found it in the book Pro LINQ written by Joe Joseph C. Rattz, Jr.

I was reading how to handle views versus tables and he says this:

"Because the entity classes generated for views do not contain entity class properties that are mapped as primary keys, they are read-only. If you consider that without primary keys, the DataContext has no effective way to provide identity tracking, this makes sense."

Mystery and problem solved.

Ben Ziegler