Got a question about the side effect of DataAdapter.Update() and
DataTable.GetChanges().

Say I set up a DataTable and a DataAdapter in a class. Delete (Not remove)
a row in the data table and call the following method.

public void JobListDataTableFromAccessCommitChange()
{
System.Data.DataTable oChangeDataTable;

try
{
if (this.jobListDataTable.HasErrors)
{
throw (new
System.ApplicationException(ErrDatabaseUpdate));
}

oChangeDataTable = this.jobListDataTable.GetChanges();
if (oChangeDataTable != null)
{
this.JobListDataAdapter.Update(oChangeDataTable);

foreach (System.Data.DataRow oDataRow in
oChangeDataTable.Rows)
{
if (oDataRow[JobDataGridViewColumnId] ==
System.DBNull.Value)
{
this.jobListDataTable.Clear();

this.jobListDataAdapter.Fill(this.jobListDataTable);
break;
}
}

if (this.jobListDataTable.HasErrors)
{
throw (new
System.ApplicationException(ErrDatabaseUpdate));
}
}
}
catch (Exception ex)
{
throw (ex);
}

return;
}


Before "this.JobListDataAdapter.Update(oChangeDataTable);" oChangeDataTable
contains 1 row. After the Update(), oChangeDataTable contains 0 row.

Does anyone knows why? The followings are some of my guesses

1. DataTable.GetChanges() contains a collection that points to the same
DataRow as the DataTable. Hence, when Update() causes the deleted row to be
removed, oChangeDataTable's collection loses the removed row.

2. The part I do not understand is if oChangeDataTable's collection still
points to the deleted DataRow, shouldn't it still be in memory and not
garbage collected?

3. Does DataRow.Dispose() has anything to do with this?

4. How is oChangeDataTable's collection is smart enough to update its count
from 1 to 0?

5. Unless the original DataTable actually maintains the change data table
and DataTable.GetChanges() simply returns a reference to this managed table?

Sorry for the bubbling here. I am typing while thinking.


--
George

I will answer my own question post here....

The side effect is caused by the AcceptChangesDuringUpdate flag in
DataAdapter. I have been passing the table obtained from
DataTable.GetChanges() into DataAdapter.Update().

This does exactly what the specification stated, but not what I wanted.

Thanks,

--
George


"George" wrote:

> Got a question about the side effect of DataAdapter.Update() and
> DataTable.GetChanges().
>
> Say I set up a DataTable and a DataAdapter in a class. Delete (Not remove)
> a row in the data table and call the following method.
>
> public void JobListDataTableFromAccessCommitChange()
> {
> System.Data.DataTable oChangeDataTable;
>
> try
> {
> if (this.jobListDataTable.HasErrors)
> {
> throw (new
> System.ApplicationException(ErrDatabaseUpdate));
> }
>
> oChangeDataTable = this.jobListDataTable.GetChanges();
> if (oChangeDataTable != null)
> {
> this.JobListDataAdapter.Update(oChangeDataTable);
>
> foreach (System.Data.DataRow oDataRow in
> oChangeDataTable.Rows)
> {
> if (oDataRow[JobDataGridViewColumnId] ==
> System.DBNull.Value)
> {
> this.jobListDataTable.Clear();
>
> this.jobListDataAdapter.Fill(this.jobListDataTable);
> break;
> }
> }
>
> if (this.jobListDataTable.HasErrors)
> {
> throw (new
> System.ApplicationException(ErrDatabaseUpdate));
> }
> }
> }
> catch (Exception ex)
> {
> throw (ex);
> }
>
> return;
> }
>
>
> Before "this.JobListDataAdapter.Update(oChangeDataTable);" oChangeDataTable
> contains 1 row. After the Update(), oChangeDataTable contains 0 row.
>
> Does anyone knows why? The followings are some of my guesses
>
> 1. DataTable.GetChanges() contains a collection that points to the same
> DataRow as the DataTable. Hence, when Update() causes the deleted row to be
> removed, oChangeDataTable's collection loses the removed row.
>
> 2. The part I do not understand is if oChangeDataTable's collection still
> points to the deleted DataRow, shouldn't it still be in memory and not
> garbage collected?
>
> 3. Does DataRow.Dispose() has anything to do with this?
>
> 4. How is oChangeDataTable's collection is smart enough to update its count
> from 1 to 0?
>
> 5. Unless the original DataTable actually maintains the change data table
> and DataTable.GetChanges() simply returns a reference to this managed table?
>
> Sorry for the bubbling here. I am typing while thinking.
>
>
> --
> George

Hi George,

You can call Update on jobListDataTable directly to update the database.
This will make things much easier. :-)

Kevin Yu
Microsoft Online Community Support

============================================================================
==========================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
============================================================================
==========================

(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Kevin,

Do you mean DataTable.Update()? I am not able to locate this public method.
Please let me know if I misundertand your previous post.

Note: Currently, I use OleDbDataAdapter.Update(<DataTable>). It does work
as I expect.

Thanks,
--
George


"Kevin Yu [MSFT]" wrote:

> Hi George,
>
> You can call Update on jobListDataTable directly to update the database.
> This will make things much easier. :-)
>
> Kevin Yu
> Microsoft Online Community Support
>
> ============================================================================
> ==========================
> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> ============================================================================
> ==========================
>
> (This posting is provided "AS IS", with no warranties, and confers no
> rights.)
>
>

No, I mean call OleDbDataAdapter.Update(jobListDataTable), which means
you're right currently.

Kevin Yu
Microsoft Online Community Support

============================================================================
==========================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
============================================================================
==========================

(This posting is provided "AS IS", with no warranties, and confers no
rights.)