updating muliple records

[Darrel]

I'm creating a table that contains multiple records pulled out of the
database. I'm building the table myself and passing it to the page since the
table needs to be fairly customized (ie, a datagrid isn't going to work).

On this page, people can update a variet of records. On submit, I want to
then go in and update all of the records.

Normally, I'd make each form element include a runat: server and then
declare it in my codebhind so I can grab it. However, since I'm building
these forms dynamically, I'm not so sure how to proceed. Can I access a form
element without having to declare it in my code behind? Are there
alternatives? Can I dynamically declare form tags as they're written?

-Darrel

[Guadala Harry]

Hi Darrel,

I currently implement something that is very much like what you describe.
I'm especially interested in seeing other answers you get to your question
because while my solution works, I'd like something a bit simpler if
possible (but that still gives me all the flexibility I need). I did a bunch
of research on this topic about 8 months ago and got nothing useful in
response - so I rolled my own and here is what I came up with (note: it
works)

1. When the page is requested I retrieve values from db/sp (into either a
DataTable - avoiding DataReaders but that would work as well).

2. Loop through the DataTable - building the output (mostly placing data
into TextBoxes, DDLs, Labels, Literals, or concatenating into a string
variable that contains raw HTML syntax - depending on what's going on in
the page)... then send the page to the user.

At this point the user is viewing the page - makes changes - then clicks a
button to post the page back.

3. Read the FORM collection to determine what is going on in the UI (to
retrieve the values from each of the user-editable controls populated
earlier).

4. Retrieve the values from the database (same stored procedure used to
populate the page in Step 1).

5. Compare values from the Form collection with values in the database - and
make any inserts/updates/deletes that may be required based on the
differences (don't need to update the db when nothing is different). This
step is necessary because the FORM collection contains only the current
values and not before/after values. So, you need some way to know what was
changed. Comparing current values from the FORM collection against the same
data used to populate the controls will give you the opportunity to discover
the changes the user has made. Anyone who has been around the programming
block more than once will see a huge risk in the assumption going on here -
but please read the rest of my post before having a heart attack at this
point.

That's pretty much it. Read the values from the FORM collection during
Postback processing. (this answers your specific question: Can I access a
form element without having to declare it in my code behind?).

For some applications, the sequence I described would lead to potentially
major data integrity problems given the assumption that the values as stored
in the database have not been modified between steps 1 and 4. A bunch of
time could pass between those steps - and the more time that passes there is
a decreased likelihood that the assumption is valid. Of course if that is of
concern, then the basic angorithm could be modified so that the data that is
retrieved in step 1 gets stored into the Session (or ViewState if that would
be a better tradeoff) and then the logic in step 5 compares the users values
(as retrieved from the FORM collection) against those stored in the Session
(or ViewState) to determine what was changed... Then from that, compare
against what's currently in the db and do any updates. Having the values
from step 1 hanging around would let you compare those against the data
store to see if any other users have made any changes to the db since you
read the db in step 1 - and then if any such concurrency issues are
discovered you could take any action necessary - thereby maintaining data
integrity in the face of multi user concurrency concerns. In any case, you
have to be very careful about how this all hangs together: because of the
reliance on the Form collection, there can potentially become a reliance on
the sequence in which values are retrieved from the db. This reliance is
definitely a problem where multi-user concurrency is of concern. Not only
can another user update an existing row, but can insert or remove rows -
thereby causing your logic - unless you are very careful - to think that
every value the user could change (in the FORM collection) was changed, when
in fact none were changed... you get the idea.

Good Luck!

GH

"Darrel" <no*****@nospam .com> wrote in message
news:ef******** ******@TK2MSFTN GP14.phx.gbl...

I'm creating a table that contains multiple records pulled out of the
database. I'm building the table myself and passing it to the page since the table needs to be fairly customized (ie, a datagrid isn't going to work).

On this page, people can update a variet of records. On submit, I want to
then go in and update all of the records.

Normally, I'd make each form element include a runat: server and then
declare it in my codebhind so I can grab it. However, since I'm building
these forms dynamically, I'm not so sure how to proceed. Can I access a form element without having to declare it in my code behind? Are there
alternatives? Can I dynamically declare form tags as they're written?

-Darrel

[Darrel]

> That's pretty much it. Read the values from the FORM collection during

Postback processing. (this answers your specific question: Can I access a
form element without having to declare it in my code behind?).

Ah! Yes, that's the answer! Simple enough.

After reading the rest of your solution, I guess I'd say that I'm thinking
the exact same thing.

The one question I had is what, if any, benefit there is to comparing the
records to ensure a change vs. just updating them all anyways (regardless of
a change)?

I suppose the argument is that if I've already loaded the values the first
time, then they're already there for comparison. The catch is that I'm doing
a recursive request to the db, so I can't just look at one ds. I suppose I
could add each record into a second ds, and use that for comparison. Hmm...

Well, at this point, I guess I do see the value in the comparison first.
However, as I'll never have more than 30 or so records, I don't think it's a
huge deal.

I do note the the issue with the time since data load vs. data submit. In
this case, the page iin question will be updated rarely, and, when so,
probably by only one person, so It's not a huge concern in this particular
case. However, I do see it being an issue down the road for larger systems.
I'll have to take that into consideration.

-Darrel

[Guadala Harry]

<<The one question I had is what, if any, benefit there is to comparing the
records to ensure a change vs. just updating them all anyways (regardless of
a change)?>>

One reason to do the comparison is because in some cases I've discovered
that the FORM collection will omit a control (e.g., textbox that is not
checked). So, we have to know what it means to have a control not included
in the FORM collection. In my case I'm not simply changing the value of
existing db rows based on user action. I'm also inserting or removing rows
from the underlying db when some checkboxes are checked. So, I can't have a
simple rule that states "always update all rows all the time and save myself
the headache of figuring when to do an update". My equivalent rule that
wouldn't work would have to be something like "always insert a row when the
checkbox exists and always delete the row when the checkbox does not exist
in the FORM collection." On the face it appears to be a reasonable rule -
but what about when a row already exists and the user does not uncheck the
box. In that case the rule would get me into trouble by inserting a second
row (or actually the insert would choke because of a primary key
constraint...). In any case the *meaning of* either the presence or absence
of a checkbox in the FORM collection is by itself ambiguous. To know the
meaning I have to know what the values were originally - thus the need to
compare before post-back and after post-back values (and the FORM doesn't
contain the before post-back info).

Separately - when it's time to save changes to the db during postback - you
might consider using a couple of arrays that contain the results of any
comparisons - and then in a couple of loops execute one or more stored
procedures to perform the db updates (yes - one execution per
insert/update/delete). You can wrap all these updates in a transaction if
necessary. Doing this might offer faster performance than manipulating your
data in a DataSet and, more importantly, might give you more control over pr
ocessing sequences. This is more of a personal thing though...I still have
nightmares from the classic ADO UpdateBatch() command... ADO.NET is very
different with respect to batch updating so you might be just as well off
with having it wrap all that logic for you...

GH
"Darrel" <no*****@nospam .com> wrote in message
news:eD******** ******@TK2MSFTN GP12.phx.gbl...

That's pretty much it. Read the values from the FORM collection during
Postback processing. (this answers your specific question: Can I access a form element without having to declare it in my code behind?).
Ah! Yes, that's the answer! Simple enough.

After reading the rest of your solution, I guess I'd say that I'm thinking
the exact same thing.

The one question I had is what, if any, benefit there is to comparing the
records to ensure a change vs. just updating them all anyways (regardless

of a change)?

I suppose the argument is that if I've already loaded the values the first
time, then they're already there for comparison. The catch is that I'm doing a recursive request to the db, so I can't just look at one ds. I suppose I
could add each record into a second ds, and use that for comparison. Hmm...
Well, at this point, I guess I do see the value in the comparison first.
However, as I'll never have more than 30 or so records, I don't think it's a huge deal.

I do note the the issue with the time since data load vs. data submit. In
this case, the page iin question will be updated rarely, and, when so,
probably by only one person, so It's not a huge concern in this particular
case. However, I do see it being an issue down the road for larger systems. I'll have to take that into consideration.

-Darrel

[Darrel]

Guadala:

I'm late getting back to you but did want to say that I really appreciate
the explanation. Thanks!

-Darrel

"Guadala Harry" <GM**@NoSpam.co m> wrote in message
news:%2******** ********@TK2MSF TNGP14.phx.gbl. ..

<<The one question I had is what, if any, benefit there is to comparing
the
records to ensure a change vs. just updating them all anyways (regardless
of
a change)?>>

One reason to do the comparison is because in some cases I've discovered
that the FORM collection will omit a control (e.g., textbox that is not
checked). So, we have to know what it means to have a control not included
in the FORM collection. In my case I'm not simply changing the value of
existing db rows based on user action. I'm also inserting or removing rows
from the underlying db when some checkboxes are checked. So, I can't have
a
simple rule that states "always update all rows all the time and save
myself
the headache of figuring when to do an update". My equivalent rule that
wouldn't work would have to be something like "always insert a row when
the
checkbox exists and always delete the row when the checkbox does not exist
in the FORM collection." On the face it appears to be a reasonable rule -
but what about when a row already exists and the user does not uncheck the
box. In that case the rule would get me into trouble by inserting a second
row (or actually the insert would choke because of a primary key
constraint...). In any case the *meaning of* either the presence or
absence
of a checkbox in the FORM collection is by itself ambiguous. To know the
meaning I have to know what the values were originally - thus the need to
compare before post-back and after post-back values (and the FORM doesn't
contain the before post-back info).

Separately - when it's time to save changes to the db during postback -
you
might consider using a couple of arrays that contain the results of any
comparisons - and then in a couple of loops execute one or more stored
procedures to perform the db updates (yes - one execution per
insert/update/delete). You can wrap all these updates in a transaction if
necessary. Doing this might offer faster performance than manipulating
your
data in a DataSet and, more importantly, might give you more control over
pr
ocessing sequences. This is more of a personal thing though...I still have
nightmares from the classic ADO UpdateBatch() command... ADO.NET is very
different with respect to batch updating so you might be just as well off
with having it wrap all that logic for you...

GH
"Darrel" <no*****@nospam .com> wrote in message
news:eD******** ******@TK2MSFTN GP12.phx.gbl...

> That's pretty much it. Read the values from the FORM collection during
> Postback processing. (this answers your specific question: Can I access a > form element without having to declare it in my code behind?).

Ah! Yes, that's the answer! Simple enough.

After reading the rest of your solution, I guess I'd say that I'm
thinking
the exact same thing.

The one question I had is what, if any, benefit there is to comparing the
records to ensure a change vs. just updating them all anyways (regardless

of

a change)?

I suppose the argument is that if I've already loaded the values the
first
time, then they're already there for comparison. The catch is that I'm

doing

a recursive request to the db, so I can't just look at one ds. I suppose
I
could add each record into a second ds, and use that for comparison.

Hmm...

Well, at this point, I guess I do see the value in the comparison first.
However, as I'll never have more than 30 or so records, I don't think
it's

a

huge deal.

I do note the the issue with the time since data load vs. data submit. In
this case, the page iin question will be updated rarely, and, when so,
probably by only one person, so It's not a huge concern in this
particular
case. However, I do see it being an issue down the road for larger

systems.

I'll have to take that into consideration.

-Darrel