locked
Propagating changes from ObjectContext to queries RRS feed

  • Question

  • Hi all,

    I'm building an app where the user edits a database table in a DataGrid. I do this by creating an appropriate ObjectQuery (using Include to get some associations), getting its ListCollectionView, and setting it as the DataGrid's ItemsSource.

    This mostly works: as the user edits the data, the ObjectContext gets the updates, including added and deleted rows.

    However, the DataGrid is not the only place of the program where changes to the table can take place. It is possible, for example, that a new record is added to the table from a separate GUI element.

    My problem is that when this happens, the DataGrid is not updated. I've checked the ObjectQuery, and sure enough, when an object is added to the ObjectContext, it does not appear in the ObjectQuery. Is there any way to get an ObjectQuery to update its content to match the content of the ObjectContext?

    Monday, November 15, 2010 5:14 PM

All replies

  • Hi Zappo1980,

    To ensure that the data source is up to date, you may need to execute the query again using the Execute method. This will bind the control to a new ObjectResult. You should do this to ensure that object data is up-to-date in the following cases:

    • Changes are being made to the same ObjectContext outside the bound control.
    • Changes are being made to data in the data source.
    • Objects were returned using the NoTracking option.

    For detailed information about ObjectQuery<T>.Execute method please refer to:
    http://msdn.microsoft.com/en-us/library/bb343787.aspx

    Best regards,

    Alex Liang

    MSDN Subscriber Support in Forum

    If you have any feedback on our support, please contact msdnmg@microsoft.com


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Tuesday, November 16, 2010 8:17 AM
  • Won't this force the DataGrid to reload all items? In my typical situation, I have a DataGrid with a thousand items or so, with frequent additions and deletions. If every addition and deletion requires the DataGrid to traverse the whole query again, it's a major problem.
    Tuesday, November 16, 2010 2:13 PM
  • Hi Zappo1980,

    It is recommended that you not bind controls directly to an ObjectQuery. Instead, bind controls to the result of the Execute method. Binding in this manner prevents a query from being executed multiple times during binding.

    Best regards,

    Alex Liang

    MSDN Subscriber Support in Forum

    If you have any feedback on our support, please contact msdnmg@microsoft.com


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Wednesday, November 17, 2010 9:42 AM
  • Thanks, I will do that. This won't solve the original issue, though. The ObjectResult doesn't change when an entity is added to the collection it came from in the ObjectContext. Therefore, if I want changes to show up in the DataGrid, I need to Execute again, which means the DataGrid has to reload everything.

    Consider this situation, which is very similar to mine. You have a DataGrid showing a very large number of records. Insertions are not done through the insertion row, but rather through a modal dialog. Deletion is done normally through the DataGrid, as well as editing of some fields. Is there any way to implement this scenario with the EF without reloading the entire table every time the user inserts a record?

    Wednesday, November 17, 2010 10:00 AM
  • I've tried doing that and, leaving aside the performance hit from reloading the whole table, I also lose the DataGrid state (selection, editing, etc). That's a showstopper. I guess I'll have to implement an additional layer between the EF and the DataGrid. Kind of a bummer though - this situation (datagrid+editing dialog) isn't particularly obscure or unusual. I'd have expected the EF to provide some way of dealing with it.
    Thursday, November 18, 2010 10:00 AM