No entities saved to DB despite successful SaveAync

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

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??

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());
        }