Working with Row State Information

From Chapter 6: Disconnected Data via ADO.NET and DataSets of the book Extending MFC Applications with the .NET Framework.

This article is a continuation of the previous article, "Doing Database Operations In Batches."

As mentioned earlier in the chapter and illustrated in the section entitled "Deleting and Removing Rows," the DataRow class defines a property called RowState that is a DataRowState enumeration with the values shown in Table 6-2.

Quick Note on This Section's Examples
This section's code snippets are all freestanding functions that can be plugged directly into your own test applications.They make the sole assumption that the DataSet and CommandBuilder objects have all been properly contructed. For example, in an SDI applicatinon you might declare each of these as member variables of the view and instantiate them (as illustrated in the section entitled "Contructing and Filling DataSet Objects") in the view's OnInitialUpdate function. This way, you can follow along, trying the various code snippets without having to see the same connection code repeasted over and over in each code example.

Table 6-2 DataRowState Enumeration Values

Member Name Description
AddedThe DataRow object has been added to the DataRowCollection object, but DataRow::AcceptChanges has not been called.
DeletedThe DataRow object—belonging to a DataRowCollection—has been deleted using the DataRow::Delete method.
DetachedEither the DataRow object has not been added to the collection or it has been removed via either the DataRowCollection::Remove or DataRowCollection::RemoveAt method.
ModifiedThe DataRow object—belonging to a DataRowCollection—has been edited, but DataRow::AcceptChanges has not been called.
UnchangedThe DataRow object—belonging to a DataRowCollection—has not changed since the last time DataRow::AcceptChanges was called.

As you can you can see, these enumeration values cover the various states of a DataRow. In fact, you can use the Visual Studio .NET debugger with the EmployeeMaintenance demo application and easily see the various states of the respective DataRow objects as you add, edit, and delete employee records. The following example illustrates the manipulation of a DataRow object and the impact of those changes on the object's RowState property. (As you've already seen examples of connecting to and reading existing data into DataSet objects, this code also illustrates how to manually define your own DataSet and DataTable objects from application data. It's not something you'll use every day, but it's definitely useful at times.)

void PrintRowState(String* currentAction, DataRow* row)
{
  Console::WriteLine(String::Format(S"{0,-20}\t\tDataRowState::{1}",
                     currentAction,
                     __box(row->RowState)));
}

void CreateAndQueryRowStates()
{
#pragma push_macro("new")
#undef new
  try
  {
    // Define a DataSet
    DataSet* dataset = new DataSet();
    DataTable* table = new DataTable(S"Players");
    dataset->Tables->Add(table);

    table->Columns->Add(S"ID", __typeof(Guid));
    table->Columns->Add(S"FirstName", __typeof(String));
    table->Columns->Add(S"LastName", __typeof(String));
    table->Columns->Add(S"Nickname", __typeof(String));
    // Create new row
    DataRow* row = table->NewRow();
    row->Item[S"ID"] = Guid::NewGuid().ToString();
    row->Item[S"FirstName"] = S"Yao";
    row->Item[S"LastName"] = S"Ming";
    row->Item[S"Nickname"] = S"";
    PrintRowState(S"Created new row", row);
    // Add row table->Rows->Add(row);
    PrintRowState(S"Added new row", row);
    // Accept changes row->AcceptChanges();
    PrintRowState(S"Accepted changes", row);
    // Edit row
    row->Item[S"Nickname"] = S"Dynasty";
    PrintRowState(S"Edited row", row);

    // Delete row
    row->Delete();
    PrintRowState(S"Deleted row", row);
  }
  catch(Exception* e)
  {
    Console::WriteLine(e->Message);
  }
#pragma pop_macro("new")
}

Plugging these two functions into a Win32 console application with Managed Extensions support and the appropriate using directives would result in the following output:

Created new row          DataRowState::Detached
Added new row            DataRowState::Added
Accepted changes         DataRowState::Unchanged
Edited row               DataRowState::Modified
Deleted row              DataRowState::Deleted

While most of this is what you'd expect after seeing the DataRowState enumeration descriptions in Table 6-2, there are a couple of things of note. First, a newly created DataRow has its RowState set to Detached until it is added to the DataRowCollection via the DataRowcollection::Add method. At that point, the RowState is initialized to Added until the DataRow::AcceptChanges method is called, at which point the RowState becomes Unchanged. Finally, note that if you call DataRow::Delete, the row's RowState becomes Deleted, and subsequently calling DataRow Collection::Remove (or DataRowCollection::RemoveAt) will not affect its RowState. The opposite is also true: Removing a DataRow from a Data RowCollection sets the row's RowState to Detached, but subsequently deleting it will not alter its RowState value.


Extending MFC Applications with the .NET Framework
By Tom Archer and Nishant Sivakumar
ISBN: 032117352X
Addison-Wesley

# # #



About the Author

Tom Archer - MSFT

I am a Program Manager and Content Strategist for the Microsoft MSDN Online team managing the Windows Vista and Visual C++ developer centers. Before being employed at Microsoft, I was awarded MVP status for the Visual C++ product. A 20+ year veteran of programming with various languages - C++, C, Assembler, RPG III/400, PL/I, etc. - I've also written many technical books (Inside C#, Extending MFC Applications with the .NET Framework, Visual C++.NET Bible, etc.) and 100+ online articles.

Comments

  • There are no comments yet. Be the first to comment!

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Given today's threat environment and the increasing connectivity of digital infrastructures, security teams now realize that they must assume their IT environments are subject to periodic compromise. Gone are the days when preventive measures to secure the perimeter or trying to detect malware problems using signature-match technologies were enough. New practices based on an understanding of the phases of an attack, continuous threat monitoring, and rapid attack detection and remediation are necessary. This …

  • Live Event Date: May 6, 2014 @ 1:00 p.m. ET / 10:00 a.m. PT While you likely have very good reasons for remaining on WinXP after end of support -- an estimated 20-30% of worldwide devices still are -- the bottom line is your security risk is now significant. In the absence of security patches, attackers will certainly turn their attention to this new opportunity. Join Lumension Vice President Paul Zimski in this one-hour webcast to discuss risk and, more importantly, 5 pragmatic risk mitigation techniques …

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds