Print Page | Close Window

No entities saved to DB despite successful SaveAync

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce 2009
Forum Discription: For .NET 3.5
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=1533
Printed Date: 21-May-2026 at 7:17pm


Topic: No entities saved to DB despite successful SaveAync
Posted By: RyanBritton
Subject: No entities saved to DB despite successful SaveAync
Date Posted: 28-Oct-2009 at 3:16am
Hi guys,

I really hope someone can help urgently - I am working on a Silverlight application and I have a very frustrating issue. On any of my forms, after I edit an entity in the silverlight dataform and save the results I recieve an ok=true result in the return arguments from SaveChangesAsync but no data is saved to the database. I have tried passing the entities to save to the SaveChangesAsync method, changing the query strategy (I thought it might have something to do with the cache), calling SaveChanges off the EntityManager in the entity in question's EntityAspect property. I've tried a single entity and multiple entities and I've ensured that I call AcceptChanges beforehand. If I enable query logging and review the log I can see that there are successful "Fetch" queries being executed against the database but there isn't even an attempt to save to the SQL server.

aaaaaarrrrgggghhhhh!

Please can someone with more experience assist? The one thing that I noticed is that the SaveOperation value in the results says "No Operation", but I am not sure what that means and if it is relevant.

Your assistance in this regard is greatly appreciated.

Ryan


Replies:
Posted By: davidklitzke
Date Posted: 04-Nov-2009 at 2:19pm

I notice below that you say that “I've ensured that I call AcceptChanges beforehand”.   Don’t do that!  AcceptChanges will change the EntityState of the Entity to “Unchanged”.  Then when you call “SaveChanges”, it will not save the Entity to the datababase because it’s EntityState is Unchanged.  SaveChanges will only save an Entity if its state is Added, Modified, or Deleted.

The other advice that I have is to look at a successful example.  There is a Silverlight example in the Learning Resources under Business Object Persistence under Adding and Deleting.

 

Posted By: dpollot44
Date Posted: 09-Apr-2010 at 6:50am
I'm running into a similar situation described below:
We're in the midst of prototyping your framework which includes code genning our own entities deriving from our own business objects, which in turn derive from your entity classes (same with the entity manager).  Within our API, the business object has an AcceptChanges() method which calls the base class's EntityAspect.AcceptChanges().  After learning that this sets the entity state back to unchanged and thereby removes it from being saved to the database, I'm left wondering why your API even includes this method?  What are the use cases for a method called AcceptChanges() that, when called, tells the EntityManager NOT to save the changes I thought I was accepting to the database??

Posted By: RyanBritton
Date Posted: 09-Apr-2010 at 7:04am
It really is a good point...anyone with any level of understanding when it comes to transactional database best practices stands a good chance of making the assumption that this is the Method which commits the transaction prior to engaging the actual data objects to perform the save.
 
A rename to "EraseAllTracesOfDataActivityAndEnterNinjaStealthMode" might be more appropriate...

Posted By: dpollot44
Date Posted: 09-Apr-2010 at 7:34am
Ha, yeah, that's sort of how I felt.  I certainly wasn't expecting AcceptChanges to push the changes to the database, but I definitely expected that AcceptChanges would push the most recent change set back to the context, and that the context would be smart enough to know that regardless of the current edit scope, the object was dirty and therefore push all of the "accepted" changed back to the database when SaveChanges() was called.  I thought that was fairly standard practice, hence my business object method below (with some of the more colorful comments removed).

        /// <summary>
        /// Pushes changes to this object (and related objects) back to the context
        /// and sets the object back to an unmodified state.
        /// </summary>
        public void AcceptChanges()
        {
            // For now these two lines are commented out because AcceptChanges(), well, sorta does exactly the opposite of
            // what the name implies, i.e., these changes will NEVER make it back to the database.

            // EntityAspect.AcceptChanges();
            // GetRelatedObjectGraph().Where(e => e.EntityAspect.HasChanges()).ForEach(so => so.EntityAspect.AcceptChanges());
           
            IsModified = false;
            IsLocked = true;
            if (null != ChangesAccepted) ChangesAccepted(this, new EventArgs());
        }


Print Page | Close Window