none
Updating the DB from another DataContext RRS feed

  • Question

  • I'm working on an application that will require me to update a number of Entities from a DataContext that is different than the DataContext that the Entities were created in.

    In a nutshell, the user interface allows the user to select a record from a DataGrid, and then after some data entry and a button click, a asyncronous process is started that eventually ends in calling SubmitChanges to update the selected record. The selected record has a number of child EntitySet and EntitiyRef fileds that are part of the update. At least part of the update must occur within a TransactionScope, so as not to allow other database users write access to some tables/records.

    In my research on what must be done to do this correctly, I've read that I must "detach" the Entitiy to be updated from it's original DataContext before I can have it updated in another DataContext. Is that correct? LINQ TO SQL seems not to provide a way to detach an Entitiy, so a little Googling brought me to this example: http://www.codeproject.com/KB/linq/linq-to-sql-detach.aspx. Are there other options for accomplishing what I need, or is this the recommended, canonical way to do this?

    Thanks,


    Bill McCormick -- MSDN Subscriber
    Monday, May 3, 2010 8:51 PM

Answers

  • Well, I was affraid I would muddy the waters with details on the other parts of the application; it seems that I have. I am not converting or serializing an EntitySet (thereby detatching it) at any point. Although I am aware of how to do this, it's not an option in this situation.

    In any event, I think that I have solved the problem, but it's sort of messy, not very intuitive and it took a lot of experimentation. What I've done is to have two seperate DataContexts: one for reading (collecting user input) data; and another for taking the user input and updating the database.

    My DataGrids DataContext is is one and is generally kept alive except that it is disposed and rebuilt for refreshing of changes made outside it's DataContext. Once the user input is complete, an asynchronous process starts and that opens another DataContext (and a TransactionScope inside of that.) User data is mapped into new Entity properties of the new DataContext and SubmitChanges is called from that scope. The result of the asynchronous operation is an resultant object that contains some additional data and some new Entities and this data and Entities are used to update the user interface, but SubmitChanges is never called on the user interface DataContext. I had to play around with some DataContext DataLoadOptions to get it to work correctly, and it seems to be working OK but it all seems a bit of hack and I'll probably work to imrpove it over time.

    Thanks,

     


    Bill McCormick -- MSDN Subscriber
    Saturday, May 8, 2010 3:05 PM

All replies

  • Actually for tasks such as this I suggest you create a stored procedure...You can create transactions using T-SQL and the T-SQL code will probably be more efficient for what you are trying to do and less complicated.

    Take a look at Scott Gu's blog on the subject:http://weblogs.asp.net/scottgu/archive/2007/08/16/linq-to-sql-part-6-retrieving-data-using-stored-procedures.aspx

     

    Tuesday, May 4, 2010 12:01 AM
  • A SP wouldn't work in my scenario because once the user selections and data entry are collected, the data are packaged into an XML file and sent to another server for some other processing. If all goes well, the other server responds with XML OK and only at that point can the DB changes be committed. If not XML OK, a rollback is done.

    I guess I left that part out of the nutshell, but it really needs to be in there.

    Thanks,


    Bill McCormick -- MSDN Subscriber
    Tuesday, May 4, 2010 1:21 PM
  • Hi Bill,

     

    Glad to see you again!

     

    Based on your second post, the entity seems to be converted (or maybe serialized) to XML file, then the XML file is converted back to the entity object at the server side?   If my understanding is correct, the entity is already in “detached” status although we do not call any detach method on it.   Then we can call Attach method on another DataContext and then the update operations can be performed.    

     

    XML Serialization and Deserialization can be really helpful in such a scenario.   http://support.microsoft.com/kb/815813.

     

    Have a nice day!

     

     

    Best Regards,
    Lingzhi Sun

    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.
    Thursday, May 6, 2010 8:50 AM
    Moderator
  • Well, I was affraid I would muddy the waters with details on the other parts of the application; it seems that I have. I am not converting or serializing an EntitySet (thereby detatching it) at any point. Although I am aware of how to do this, it's not an option in this situation.

    In any event, I think that I have solved the problem, but it's sort of messy, not very intuitive and it took a lot of experimentation. What I've done is to have two seperate DataContexts: one for reading (collecting user input) data; and another for taking the user input and updating the database.

    My DataGrids DataContext is is one and is generally kept alive except that it is disposed and rebuilt for refreshing of changes made outside it's DataContext. Once the user input is complete, an asynchronous process starts and that opens another DataContext (and a TransactionScope inside of that.) User data is mapped into new Entity properties of the new DataContext and SubmitChanges is called from that scope. The result of the asynchronous operation is an resultant object that contains some additional data and some new Entities and this data and Entities are used to update the user interface, but SubmitChanges is never called on the user interface DataContext. I had to play around with some DataContext DataLoadOptions to get it to work correctly, and it seems to be working OK but it all seems a bit of hack and I'll probably work to imrpove it over time.

    Thanks,

     


    Bill McCormick -- MSDN Subscriber
    Saturday, May 8, 2010 3:05 PM