How to update a data table from a textbox

jsn1

Member
Joined
Jul 14, 2006
Messages
12
Programming Experience
10+
Hi all,

I created a form with several textboxes, and a datatable that I have bound to the text boxes. When I update a text box and I click on the button "Save", I do not know how to save the new value on the datatable.

thanks
jsn
 
If you have bound textboxes then the changes you make in the textboxes will automatically be reflected in the underlying table. As far as updating the datatable goes, thats all you have to do.
 
I created the datatable, and it has data. In my windows form I have a tabControl with two tabs:
- one for the list, with a datagrid that displays the content of the datatable,
- another tab called "detail" that displays the record selected on the datagrid. Here the user can modify a text box. And I would like to save the modification in the datatable. Otherwise when the user switchs between the tabs "List" and "Details", the modifications entered in the text box are not visible in the datagrid.


Probably I am missing the "Me.BindingContext()"

I do not know how this BindingContext works.

jsn
 
vis781 said:
If you have bound textboxes then the changes you make in the textboxes will automatically be reflected in the underlying table. As far as updating the datatable goes, thats all you have to do.

Mmmhmm, kind of. The row in the underlying datatable has several states and versions, and a value can either be original, modified, proposed, detached etc.. I have a good tutorial lying around somewhere that explains the row states and how they change, but the info is just as easy to find on google by searching for DataRowState and DataRowVersion..

couple of example hits:
http://www.codeguru.com/cpp/cpp/cpp_managed/general/article.php/c6799/
http://www.ondotnet.com/pub/a/dotnet/excerpt/progvisbasic_ch08-2/index.html?page=3
 
No, not kind of.. exactly. Thats what databinding does. DataRowState is separate. The datarowstate will change according to what changes have been made in the underlying table, so the dataadapter can correctly identify what OleDbcommand, sqlcommand etc.. to associate with that datarow during an update. It has nothing to do with binding, the rowstate property is changed whenever a change is made to a datarow in the datatable, bound or not.
 
I think you misunderstand my point - after you have used a textbox to cause an underlying databound table to be updated, it is still possible, by some programming routes, to make it appear that the update did not take place..

Yes, you are correct; a databound textbox will normally (validation concerns aside) always cause an update to occur to the underlying table, but no, i dont feel your answer went far enough to point out that there might be circumstances in which it looks as though the update did not occur..

Some analogue might be found in a transactional database system; you can issue an update and it really looks like you updated, but until you commit the change, it will evaporate when the transaction is rolled back. While I dont mean to assert that datatables are transactional, I do mean to make the OP aware that the data you see in context X is not the only data available in all contexts nor the only data the table holds. :)

vis781 said:
It has nothing to do with binding, the rowstate property is changed whenever a change is made to a datarow in the datatable, bound or not.
This statement is almost contradictory? It has something to do with the binding in this case, because it is due to the fact that the row is bound to a textbox for display/edits that brings about the change to the row, that you correctly observe affects the row state.. Note also I mentioned DataRowVersion.. this is a separate concept to the state. Sorry if you missed that, as it was less present in my post than the mention of the sate was (perhaps in error as DataRowVersion is more significant to my point)
 
I think you misunderstand my point - after you have used a textbox to cause an underlying databound table to be updated, it is still possible, by some programming routes, to make it appear that the update did not take place..

Yes, you are correct; a databound textbox will normally (validation concerns aside) always cause an update to occur to the underlying table, but no, i dont feel your answer went far enough to point out that there might be circumstances in which it looks as though the update did not occur..

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.

This statement is almost contradictory?

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.


jsn1 had a question as to why he could not see the changes in his datagrid, this is a databinding issue, from the question i assumed that jsn1 has not been using ADO.Net for an extensive period of time (no offence intended jsn1) so to further complicate a straightforward question with unrelated issues of datarowversions/datarowstates seems inappropriate on this thread. In any case DataRowVersion is also totally unrelated in this case as jsn1 was not trying to make an update to a database.
 
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 :)
 
ok, agreed and maybe i was a bit harsh to depose your reply in the way that i did. It is, as you said in a separate thread, sometimes difficult to determine the tone of a post. What you have said is correct and i understand where yuor coming from. I'm just a believer in simplicity, and invariably it's the best way to go, being as computers are about as simple a thing as you can get in terms of what they can understand. Anyway i've no doubt that this thread is being watched to make sure it doesn't go off topic, and i don't want this thread locked just in case jsn1 has something to add. So it's all good, and i enjoyed the debate cjard:)
 
I found the problem, when I binded the combobox, I used the same syntax as a textbox, so the updates I made on the combo box where not registered.

' bind combobox
'
Me.cbDetailStatus.DataSource = dtStatusDataTable
Me.cbDetailStatus.DisplayMember = "Name"
Me.cbDetailStatus.ValueMember = "Name"
Me.cbDetailStatus.DataBindings.Add("SelectedValue", dtMainData, "Status")

Initially I wrote
Me.cbDetailStatus.DataBindings.Add("text", dtMainData, "Status")

the word text is used in textboxes for combo boxes you must use SelectedValue

thank you for your help
jsn
 
To further this a little.. What you say is true in one case.

A Combobox is a 2 part component. it has a Textbox and a DropdownList. A combobox has several styles of display.

In simple mode, the dropdown list is hidden, though i think you can still scroll its values with the cursor keys and the shown text will change. I use this mode usually for when I want to display something, based on some other value. As you have found, with the DisplayMember and ValueMember properties.. a Database table might contain 1,2,3 that map to Mr, Mrs Miss etc - you want to display the Mr but store the 1.. Suppose in a grid we have a column of person titles, you can either write a query that does a join and returns the Mr as text, or you can return the 1 and use a Combo to look up and show the Mr. Using SIMPLE style hides the dropdown arrow for better readability of your grid (at least thats when i use it)

In DropDown style it functions like the internet explorer Address bar: you can type free text into it, or you can select from the list. In this case it is the .Text property that is updated when you type into it or choose from a list. If your combo is being used in DropDown style you would databind to the .Text property

In DropDownList style, it functions like what most people think a combo is - a list of values and you must choose one. You may not type your own free entries, you must pick one from the list. In this mode you do indeed set things up as you say, with selectedvalue etc..


Interestingly, I note that you say you found the problem, which is good, but your first two posts to this thread dont actually mention that youre having a problem with the combo box - merely that you were asking how to save data to a datatable? perhaps we could have advised you sooner of the SelectedValue thing, if you'd mentioned what the problem actually was.. ?
 
Back
Top