G
Guest
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.
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.