Recently, I was tasked to write an ASP.NET application that allowed a user to make corrections to his data, validate the change on a specific row and save the change back to the Oracle database. Also, if a user clicked the refresh hyperlink, he could reset the values for that specific row back to the original values. The application would also allow the user to search for a specific domain value via a popup window and save the value back to the designated field of the specified row. This application had to dynamically identify the table that needed correcting. This table was identified by getting the scheme and table name from a configuration table. Now, for this version, release 1, the columns were static and easily identified.

For release 2 of this same application, the column names were generated dynamically and were no longer static. Since each department in the company had different naming conventions for its table definition, we could not assume that we knew what the column names would be.  So now, we had to identify the table and the columns dynamically. I also used the DataGrid in this project so that the customer could navigate throughout the entire recordset via the DataGrid’s paging capability and make changes to any row within the Table object. Furthermore, the controls inside of the DataGrid would dynamically show only those columns that were used by a specific system. For example if your key values consisted of three columns then only those three columns would be rendered to the screen, and if the key column consisted of only one column then only that one column would be shown. This was a very dynamic DataGrid that changed when the configuration table changed.

The solution was to use a DataSet to save and manipulate the data. I was not a fan of the DataSet and I felt that it was often overkill. I mean really guys, how many developers would find a need to manipulate more than one table within a DataSet? But, after working on this project, I am more of a fan now. Well, I am really a fan of the DataTable and the DataRow not the DataSet. But, since I cannot populate a DataTable without the DataSet, I am now a DataSet fan.

What was most exciting about the DataTable was how easy it was to identify a row that needed updating. To identify the row, the DataRowCollection provides a method called Find(). This method acquires a specific row identified by the array of primary key values passed to it.

Example:

DataRow FoundRow;
object[] PrimaryKeyValues;

PrimaryKeyValues[0]= "Keith";
PrimaryKeyValues[1]= "Wells";
PrimaryKeyValues[2]= "Louisiana";
PrimaryKeyValues[3]= "GROUP1";

FoundRow = MyDataTable.Rows.Find(PrimaryKeyValues);
if (FoundRow!=null)
   {
      FoundRow.BeginEdit();
      FoundRow["COLUMN1"] = "NEWVALUE1";
      FoundRow["COLUMN2"] = "NEWVALUE2";
      FoundRow.EndEdit();
    }

Once you identify the row in the DataSet using the values from the DataGrid, all you need to do then is assign your new value to the row object as illustrated above.

Now, remember that there was also a requirement to reset the row back to its original value when the refresh link was clicked. Can you imagine what it would have taken to implement this capability in classical ASP? The entire project would have taken three times as long. First of all, I would have needed a temporary working table available when making changes to the recordset so that I could keep track of the changes made. I also needed a reference back to the row’s original value. All of this just to be able to reset the row back to its original values.

It should also be known that temporary tables in Oracle are different than in SQL Server. In SQL Server, you can create a temp table dynamically, on the fly, but in Oracle you have to create the definition in advance. This is a weakness in Oracle. Although I would have a unique instance for each user in Oracle, the problem with Oracle is that my user’s table structure would change depending on the department that was using this application. For example, Department A may not carry the “SSN” column but Department B might carry the “SSN” column. I needed the ability to dynamically create my temporary tables based on the columns defined in the configuration table. Also, I needed the ability for 1 to n number of users to be able to make changes to their data. This meant that for each user session, there would have to be a temporary working table available to track changes.

The DataRow object just made this way too easy. I did not have to do anything to fulfill these requirements using ASP.NET!

The DataRow object automatically keeps track of the original value and the current value! I couldn’t ask for more! See the code below.

//Reset column back to its original value
FoundRow["COLUMN1"] = FoundRow["COLUMN1",DataRowVersion.Original];

//Set column back to its modified value
FoundRow["COLUMN1"] = Row["COLUMN1",DataRowVersion.Current]

The above code is all that is needed. The DataRow automatically saves this information. That is all there is to it! This saved me hours of coding!  This feature also made it simple for me to create an audit log. The audit log tracked all changes made to the row. This log needed to log the original value and the new value. With the above code, this was a simple process. This capability is already built into the DataRow object.

I wanted to bring to light how easy it was to implement the requirements of this project by using the DataSet, the DataTable and the DataRow.  I hope this article was enlightening. Happy Coding!