vis781 said:
Agreed, through Accept/Reject changes etc However both these points are mute seeing as the original poster had not called these subs and are not relavent in this case.
Yup, though not just by accepting or rejecting changes (which in themselves use DataRowVersion i think).. there are other ways without causing a data change, of interrogating multiple values for one datatable cell.. I was widening the answer you gave (hence the mmmm agreement)..
I'm baffled, it's not contradictory at all, it is fact. Databinding does not affect the rowstate at all. Only user input altering the bound control can affect the rowstate.
Both true statements, and a point presented to me in this way far more clearly than previously. Binding is the way by which a control is connected with the data it is to update and display (MVC notion) and this in itself does not cause a change to the rowstate, but it is the mechanism by which the change is delivered so you can say that a databinding is used to cause change. The way I read into your original post, it wasnt quite clear. From what I read, you seemed to be saying that binding and changing data are unrelated concepts.. I couldnt understand this because binding is the mechanism that delivers change.
To use an analogy, I thought you were saying that delivery of products to a supermarket (data/change) has nothing to do with roads (binding).. This is why I queried it..
jsn1 had a question as to why he could not see the changes in his datagrid, this is a databinding issue,
It might be - or it might be that the data has changed and the datagrid has not become aware of the change. In MVC, this would be the case of a data model M, having a controller C as the textbox (which also actas a a view implicitly) and a View V in the datagrid - it's necessary that soemthing happen programmatically for the model or the controller to notify the View of the change. The logical place is to have the model do it, as it may be used by several controllers and the onus should hence be on the model, for best encapsualtive practice and minimum coupling.
so to further complicate a straightforward question with unrelated issues of datarowversions/datarowstates seems inappropriate on this thread.
perhaps this is true; maybe j1n will return with a related query soon, maybe he will not. SOmetimes I answer only the question at hand, sometimes I provide additional information.. Any ensuing debates are usually a more constructive form of information rather than destructive form of rabbling, and I find you (and others like you) a fascinating source of information on various topics; What better way to enforce in our mind that which is correct, than by to teach it to others?
In any case DataRowVersion is also totally unrelated in this case as jsn1 was not trying to make an update to a database.
This too puzzled me; DataTables are far abstracted from database if you ignore the notion that they are themselves a store of data and hence, a database. I checked on MSDN and found that DataRowVersion has nothing to do with the underlying persistent data storage that a DataTable uses; DataRowVersion is very relevant to the use of a datatable as it is used in tandem with DataRowState to decide the fate of data in Accept oor Reject operations.. Take a check for yourself.. DRV is a DataTable internal management concept, unrelated to SQLServer/Access or other DB Techs
- Note this point isnt meant to be inflammatory, I am, again, just encountering a situation whereby what I've read into what you have written, contradicts the previous knowledge I had of the topic.. (And hence I'm doublechecking)
http://msdn2.microsoft.com/en-us/library/system.data.datarowversion.aspx
There's no doubt in my mind, that it'll end up where we were talking from two different perspectives of the same concept, both correct