If you manually bind to a DataTable, I think the page will try to place the data table into the page's ViewState and recreate it when the page posts back.  So, when the page posts back, you might end up with the bound DataTable being a different instance than the DataTable within the BO that is saved off in a session somewhere.  You also might consider using an ObjectDataSource to bind the business object if you don't want to use the SF data binding.

Hmmm... I'm guessing that this would work. I know that the BO determines if it's dirty by looking at the underlying datatable and if any row is changed, it is dirty. I also know that typically, the Save() updates the UI. But I've not done any web stuff, so I don't know if the web version of the save is different. I'm curious now too!

Good question. I was doing exactly the opposite today in a Winform, I didn't want the changes in the datatable to make it back to the BO so I used the datatable's copy() method to create a new unique instance of the datatable for each UI element that could then function independently.



I had to go through that because changes to the BO's datatable always caused databound events to fire that I didn't want.



I will be interested how this works through postback in a web app.








Keith Chisarik

In my web application - as an alternate binding technique - I can easily access the SF business object's DataTable and manually bind my various UI controls to it.

Once the user edits the data in the UI and the page posts back - how can I get those changes back into the SF business object's DataTable in an efficient way?  Once the changes are back into the object's DataTable, will SF then do its magic when I call the Save() method?

Cheers!

Keith