The documentation of DataTable.LoadDataRow() has a major omission. To
quote:

"Finds and updates a specific row. If no matching row is found, a new row is
created using the given values."

What this does NOT tell you is that it ignores any rows which have the
INSERTED or UPDATED flags set. It only correctly updates the data table if
you have already called AcceptChanges() on your data table.

Well, this little omission costed me HOURS of work. I designed a routine
to update an entire dataset (including a number of data tables) in one big
swoop so that I can call Update() inside a transaction to do all the inserts
and updates at one time. Unfortunately, that routine fails miserably due to
duplicated keys. This occurs when you call LoadDataRow() more than once
with the same primary key expecting an UPDATE to an existing row AS THE
DOCUMENTATION STATES!

At a minimum the documentation needs to be corrected. On the other hand,
most every other function that can affect rows in the data table gives you
the ability to specify flags indicating which rows to ignore. Why on earth
wouldn't that be available on this function?

Yep, one more example showing that it would be better to use business
objects and not to rely on DataTables and DataSets.
IMHO.

"John Viele" <johnv@{NO_SPAM}goisc.com> wrote in message
news:%23quPF%(E-Mail Removed)...
> The documentation of DataTable.LoadDataRow() has a major omission. To
> quote:
>
> "Finds and updates a specific row. If no matching row is found, a new row
is
> created using the given values."
>
> What this does NOT tell you is that it ignores any rows which have the
> INSERTED or UPDATED flags set. It only correctly updates the data table
if
> you have already called AcceptChanges() on your data table.
>
> Well, this little omission costed me HOURS of work. I designed a routine
> to update an entire dataset (including a number of data tables) in one big
> swoop so that I can call Update() inside a transaction to do all the
inserts
> and updates at one time. Unfortunately, that routine fails miserably due
to
> duplicated keys. This occurs when you call LoadDataRow() more than once
> with the same primary key expecting an UPDATE to an existing row AS THE
> DOCUMENTATION STATES!
>
> At a minimum the documentation needs to be corrected. On the other hand,
> most every other function that can affect rows in the data table gives you
> the ability to specify flags indicating which rows to ignore. Why on
earth
> wouldn't that be available on this function?
>
>