William
Fri Mar 05 08:36:27 CST 2004
Hi Mike:
"Mike Lerch" <mlerchNOSPAMTHANKS@bigfoot.com> wrote in message
news:6s1h40t3fkaru6kkqi21k11ro1vl5i47ls@4ax.com...
> On Thu, 4 Mar 2004 13:47:52 -0500, "William Ryan eMVP"
> <dotnetguru@comcast.nospam.net> wrote:
>
> >You'll want to define an Update Statement, Insert Statement, Delete
> >Statement and a Select Statement. If you have a keyed table, you may
> >consider using a commandBuilder (although I tend to avoid them) and just
> >give it a Select, it will infer the rest for you. Check out Bill
Vaughn's
> >article here
>
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnadonet/h
t
> >ml/commandbuilder.asp
> >or his other stuff at www.betav.com
>
> Thanks, William and Mortos, this was great. One more question:
>
> I assume that I need to "wire up" (for lack of a better word) the
> insert/update statements?
>
> Here's the narrative: In that case I'm working with, I am using
> nested repeaters to present hierarchical information. If someone goes
> into one of the child textboxes and makes a change, then clicks a
> button on the form to fire the update, do I need to go find the
> repeaters that have changed info and enter them as parameters to the
> update procedure? (because it will be a parameterized stored
> procedure). I'm thinking that I have to do that but am wondering
> about the relation between data that the DataAdapter knows has changed
> with the physical instances of the repeater.
>
> Aw, hell, I'm barely following: this is too big for my brain today!
>
> Lerch
If you look at the code generated when you run a DataAdapterConfiguartion
wizard for instance, you'll see the last argument of the parameter
declaration is a field name - this is actually the ColumnMapping which maps
that column back to the database. So anything that's inserted in a given
row in whatever column will be used as that parameter's value. Also
remember that the DataAdapter (until version 2.0 anyway) updates records one
at a time.) Ok, so if you add a new row and set the value of Column2 to
"Bill" then add another one and Set it to "Lerch" we have two new rows and
the paratmers @Column2 will have each of those values.
This is how one part of the mapping takes place. If you are updating
everything programatically without a UI, then this is pretty much all there
is to it. However, if you are using a UI, then you can either use the
values of the controls and manually set the values of the underlying table
accordingly, or you can use DataBindings. If you use Bindings, you have to
reference a specific field of a DataTable/DataView. So if we had a textbox
and used myTextBox.DataBindings.Add("Text", myDataSet, "Column2") everything
we did to that textbox would be reflected in the given record's Column2
column. This would then be mapped to parameter @Column2 which is part of
the insert statement. When the update is fired and the DataAdapter sees a
row marked as Inserted (or Modified/Deleted etc) then it will use this
value.
The BindingContext will take care of moving the position of the current row
and then the UI is used to modify/insert/delete values. IF you only have a
grid, then you don't even necessarily need to specify a context you can just
set it's datasource property. Also,I used the DataAdapter Configuration
wizard as my example above, but whatever way you create your update logic,
you can explicitly create the mappings (like the Wizard does) or you can
just set the param values manually without the mapping.
Using DataBindings makes this a whole lot easier though b/c everything is
mapped behind the scenes and it's very straightforward to deal with.
HTH,
Bill