This second week we will cover the parts of the chapter we didn't cover the  first week:

• Flat files
• XML data

A reminder:  chapters 5 and 6 in Kalani discuss the subject of ADO.NET,  which is so different from "classic" ADO that it would be dangerous for you to assume that it's a simple extension.

The  code examples for chapter 5   (Data Binding,  remember)  are still relevant to the classes listed below.

The problem is that the subject of this chapter is the most open-ended one in Kalani.   Kalani covers the subjects of all the other chapters almost completely,  but in this one there is no telling what information should be added.   (In other words, this chapter in Kalani—don't scream—is probably 30 pages too short.)   You don't have to worry about memorizing all of the information below,  and you don't have to know it in depth;  but I am confident that you will be rewarded if you spend time wandering through this subject,  picking up details where you can.

Remaining Topics from Kalani's chapter 6

• The namespace:  System.IO
• The  File  class.   Its public methods are all static.   Security checks are done for every method call.   Example of use:  Kalani,  pp. 467-8
  • Copy(), Create(), CreateText(), Delete(), Move()
  • Open(), OpenRead(), OpenText(), OpenWrite()
  • Exists().   Returns true or false
  • Get or Set—
    • Attributes()
    • CreationTime(), CreationTimeUtc()
    • LastAccessTime(), LastAccessTimeUtc()
    • LastWriteTime(), LastWriteTimeUtc()
• The  FileInfo  class.   None of its public methods are static.   You create an instance before you use it.   Security checks are done only once,  when the  FileInfo  object is created.
  • Constructor:  FileInfo(string fileName)
  • Other methods are similar to those in the  File  class,  but not identical.
• The  Directory  class.   All methods are static.
• The  DirectoryInfo  class.   None of its methods are static.
• The  FileStream  class.   Treats a file as a stream of bytes.   Examples:  Kalani,  pages 469-70,  472.
  • Construct it with,  say,  File.OpenRead()
  • Read(), ReadByte() 
  • Write(), WriteByte() 
  • Flush() 
  • Close() 
  • There's no  Open().   You use the File  class for that.   See Kalani's example.
• The  StreamReader  class.  
  • Constructor:  StreamReader(Stream stream)
    (Construct a  FileStream  first,  then construct a  StreamReader  on it.)
  • Peek()
  • Read(), ReadBlock(), ReadLine(), ReadToEnd()
  • Close()
  • Again, no  Open().
• The  StreamWriter  class.  
  • Constructor:  StreamWriter(Stream stream)
    (Construct a  FileStream  first,  then construct a  StreamWriter  on it.)
  • Write(), WriteLine()
  • Flush()
  • Close()
  • Again, no  Open().
• The  BinaryReader  class.   The problem here is knowing exactly how to read each piece of data.   You have to know exactly how it was written.
  • Constructor:  BinaryReader(Stream stream)
    (Construct a  FileStream  first,  then construct a  BinaryReader  on it.)
  • PeekChar()
  • Read()   (characters)
  • ReadBoolean()
  • ReadByte(), ReadBytes()
  • ReadChar(), ReadChars()
  • ReadDecimal()
  • ReadSingle(), ReadDouble()
  • ReadInt16(), ReadInt32(), ReadInt64()
  • ReadSByte()
  • ReadUInt16(), ReadUInt32(), ReadUInt64()
  • ReadString().   The obvious problem here is to know the length of the string to read.   I'm afraid the on-line documentation is little help:  "Reads a string from the current stream.   The string is prefixed with the length,  encoded as an integer seven bits at a time."   Does that mean that the string will tell you how long it is as you read it in?
• The  BinaryWriter  class.   It doesn't work the way you thought it would.   The class doesn't just copy the methods in the BinaryReader  class and change the names a little;  The  Write  operator is overloaded; 
  • Constructor:  BinaryWriter(Stream stream)
    (Construct a  FileStream  first,  then construct a  BinaryWriter  on it.)
  • Seek()
  • Flush()
  • Close()
  • Write(output).   Here's where you do all the work,  because  output  may be any of the following types:
    • bool
    • byte, byte[]
    • char, char[]
    • decimal
    • float, double
    • short, int, int64
    • sbyte
    • string.  Lots of luck reading it back it.
    • ushort, uint, ulong
  • Needless to say,  you have to remember exactly how all these fields were written to have any hope of reading them back in with the  BinaryReader.

XML

• You do know about XML,  don't you?
• Namespace containing the C# classes:   System.XML
• The XML declaration at the top of the file:

      <?xml version="1.0" encoding="UTF-8"?>

• The  Node  class.   It's one element in an XML tree.
  • Descriptive properties of a node:   Name, Value, NodeType
  • Possessions of a node:   ChildNodes, InnerText, InnerXml, OuterXml
  • Pointers to relative nodes:   FirstChild, LastChild, NextSibling, ParentNode, PreviousSibling
  • Methods affecting nodes:   AppendChild(), InsertAfter(), InsertBefore(), PrependChild(), RemoveAll(), RemoveChild(), ReplaceChild()
  • The "root node",  being the one at the top of the tree,  "contains"  all the others.
• The  XmlDocument  class.   It contains the  Node  objects described just above.   It represents the entire XML  "file"  in memory,  implementing a Document Object Model (DOM).  
  • Actions within the document:  CreateAttribute(), CreateElement(), CreateNode()
  • The whole document:  DocumentElement.   A property that returns the root node of the document.
  • Input and output:
    • Load().   Loads an XML document into an  XmlDocument  object
    • LoadXml().   Loads a string of XML data into an   XmlDocument  object
    • Save().   Saves the   XmlDocument  as a file or stream
    • WriteTo().   Saves the  XmlDocument  to an  XmlWriter 
  • To display an entire XmlDocument,  you will need a recursive routine to display the tree.   Example:  Kalani,  pages 530-531.
  • It may sound obvious,  but keep in mind the difference between an  XmlDocument  and a DataSet.   There will be more about DataSets and XML toward the bottom of this web page.
• The  XmlDataDocument  class  allows you to treat the XML document like relational data,  and thus similarly to a DataSet.   This class "inherits from  XmlDocument."   Its "key feature...is that it can be synchronized with a Dataset object."   (Kalani,  page 534,  bottom)   On page 535,  Kalani has an example of using an  XmlDataDocument  to read an XML file into a DataSet.   It includes reading the XML schema before reading the XML data.   (This is not the only way—perhaps not even the best way—that you can read an XML file into a DataSet.   We will hit the others much farther down on this web page.)
• The  XmlTextReader class
  • Derives from the abstract  XmlReader class
  • Has a lot of properties and methods
  • Can read from a stream
  • Works forward-only
  • Doesn't validate the XML against a schema.   (We will cover validation later on this page, too.)
• The  XmlTextWriter class
  • Derives from the abstract  XmlWriter  class
  • Works forward-only
  • Has a lot of "write" methods,  which you don't need if you're just writing out an entire document.   You use the XmlDocument's  WriteTo()  method to pass data to the XmlTextWriter;  then flushing and closing the XmlTextWriter writes the file.   Here is an outline of code from Kalani's example on page 533:

                //Read the external file
    
              XmlTextReader xtr = new XmlTextReader(inputFileName);
              XmlDocument xd = new XmlDocument();
              xd.Load(xtr);
              xtr.Close();
    
              //Work with the document after retrieving its top node
    
              XmlNode xnod = xd.DocumentElement;
              ....
    
              //Write the document
    
              XmlTextWriter xtw =
                new XmlTextWriter(outputFileName, System.Text.Endcoding.UTF8);
              xd.WriteTo(xtw);
              xtw.Flush();
              xtw.Close();

• DataSets and XML:
  • Kalani doesn't talk about the  ReadXml()  and  WriteXml()  commands,  which write directly from a DataSet to an output.   But we do,  at the bottom of this web page.

DataProviders and SQL

• The arguments in the SQL  ConnectionString,  (Help: "SqlConnection.ConnectionString Property";  "integrated security" for general info)
  • There are some synonyms here:
    • Integrated Security  or  Trusted_Connection
    • Initial Catalog  or  Database
    • Data Source  or  Server  or  Address  or  Addr  or  Network Address
    • Password  or  Pwd
  • If you specify a new  ConnectionString,  no settings  (such as the database name)  persist from the previous setting.
• The  Prepare()  command, what it does, and when you would use it   (Help: "SqlCommand.Prepare method";  Beauchemin 92)
  • The on-line Help says, "Creates a prepared version of the command on an instance of SQL Server."
  • It's like  ngen:  you set the command type and parameters,  then call  Prepare  for this command to have the SQL engine set it up so that it runs faster the first time.
  • But since it takes a round-trip to the server,  it's of questionable usefulness.
  • You don't use  Prepare  for each call to the command;  only for the first one.
• "SET NOCOUNT ON" in SQL.   Small point,  but it has come up:
  • It's an optimization feature in SQL.   If turned on, it avoids returning a count from the server after each separate SQL operation.   Since there can be several SQL operations in one stored procedure, setting NOCOUNT on might save a few trips from the server.   (Help: "SET NOCOUNT" in Transact-SQL Reference) 
  • The @@ROWCOUNT value is still updated even if NOCOUNT is ON.
  • The values returned to a C#  ExecuteNonQuery()  command are not affected.
  • This statement can be placed at the start of a stored procedure.   But how long is it effective?   Just for this procedure?   Or is it effective across all SQL calls until cancelled?   Aha!   "If a SET statement is set in a stored procedure, the value of the SET option is restored after control is returned from the stored procedure.   Therefore, a SET statement specified in dynamic SQL does not affect the statements that follow the dynamic SQL statement."   (Help: "SET (described)" in Transact-SQL Reference)
• How to use  SqlCommandBuilder()  and how to get its commands to the  DataAdapter  object   (Help: "SqlCommandBuilder class";  Beauchemin 200, 45;  examples, 200, 42-43)
  • Remember that you must somehow specify the  UpdateCommand  and the other commands for the DataAdapter;  it won't assume them.   Incidentally,  you may specify stored procedures for these commands.
  • CommandBuilder  works by creating these commands and letting the DataAdapter know about them.   Here's the simplest example from Beauchemin (page 200):

              SqlDataAdapter da = new SqlDataAdapter(
              "Select * from jobs",
              "server=localhost;uid=sa;database=pubs");
            SqlCommandBuilder bld = new SqlCommandBuilder(da);

  • Set up this way,  CommandBuilder  does not set values for the UpdateCommand and other commands needed by the DataAdapter.   It sets a delegate,  and supplies the commands as they are needed at the  RowUpdating  event.  
  • CommandBuilder  creates these commands by examining the  Select  command you gave the DataAdapter.   This means that your SQL Select command must exist at the time that the  CommandBuilder  needs it.   You can't expect  CommandBuilder  to make up the three other commands without help.
  • You can get at the commands created by  CommandBuilder:  use,  for instance, 

               da.InsertCommand = bld.GetInsertCommand();

    But if you do this  (in order to supply your own version of the command),  you must inform the  CommandBuilder  by commanding

               bld.RefreshSchema();

  • CommandBuilder  commands can only work on a single table—they cannot update JOINed tables.
  • Finally,  remember that you get all four SQL commands created for you automatically when you create a DataAdapter by dragging a table from the Server Explorer to your desktop.   And that gives you "optimistic" concurrency for your updates.
• SQL Transactions
  • Although commands and transactions are both created on a Connection object,  the command is not automatically assigned to the connection's transaction;  you must explicitly set the command's  Transaction  property to the proper transaction.
  • The two arguments to  BeginTransaction  are both optional:   (Help: "SqlConnection.BeginTransaction method";   example, Beauchemin 107)
    1. IsolationLevel
       • On-line Help:   "Specifies the transaction locking behavior for the connection."
       • Enumeration:  IsolationLevel.ReadCommitted, ReadUncommitted, RepeatableRead, Serializable, Unspecified,  and,  my personal favorite,  Chaos.   (Only .NET would think that Chaos had to be precisely specified.)   Of these,  only  Serializable  keeps the lock on the data until the end of the transaction.   (Help: "IsolationLevel enumeration")
    2. Name,  applied to the transaction.   This may be used in Rollback operations;  see below.    (Beauchemin 110)
  • Nested transactions   (Help: "OleDbTransaction.Begin Method";  Beauchemin 109)
    • Who supports them?   SqlServer apparently does not,  though Access does—the required classes only seem to exist in  OleDb,  not in  Sql.   (Beauchemin's page 109 example uses Acess)
    • Inner nested transactions use  outerTransaction.Begin()   instead of   connection.BeginTransaction(),   the way the outermost transaction does
    • Here is an even shorter version of Beauchemin's page 109 example:

                    OleDbConnection conn = new OleDbConnection("....");
                  //Outer transaction is based on the Connection
                  OleDbTransaction outerTrans = conn.BeginTransaction();
                  //Command needs to know about both the connection and the transaction
                  OleDbCommand outerCmd = new OleDbCommand("update....", conn, outerTrans);
                  ....
                  //Inner transaction is based on the outer transaction, not the connection
                  OleDbTransaction innerTrans = outerTrans.Begin();
                  //Command needs to know about both the connection and the transaction
                  OleDbCommand innerCmd = new OleDbCommand("update....", conn, innerTrans);
                  ....
                  //Roll back inner transaction
                  innerTrans.Rollback();
                  ....
                  //Commit outer transaction
                  outerTrans.Commit();

  • Named savepoints and rollbacks:   Save(name)  and  Rollback(name)   These are allowed by SQL Server.   (Help: "SqlTransaction.Save Method";   Beauchemin 110)     Here are some lines from Beauchemin's example:

              SqlTransaction sqlTrans = conn.BeginTransaction();
            ....
            command.Transaction = sqlTrans;
            ....
            sqlTrans.Save("savepoint");
            ....
            sqlTrans.Rollback("savepoint");

DataSets and associated classes and methods

• DataSet  members  
  • DataSet.Clone()  vs.  DataSet.Copy()—exactly what each does.   Clone()  copies only the structure of a DataSet,  whereas  Copy()  copies all the DataRows along with the structure.   (Help: "DataSet.Clone method";  "DataSet.Copy method"; Beauchemin 149-150)
  • GetChanges()
    • Here's on-line Help on the subject:  "Gets a copy of the DataSet [or DataTable] containing all changes made to it since it was last loaded, or since  AcceptChanges  was called."
    • How do you get a particular kind of change to the DataSet or DataTable?   You call  GetChanges()  with an argument:

                  DataSet GetChanges(DataRowState);

      Now,  pay attention:  it's the  DataRowState,  not  the DataViewRowState.   I believe this is one of the few times you will actually use DataRowState in your programming,  as opposed to DataViewRowState.   The enumerations for both of these items are given below.   (Help: "DataSet.GetChanges method";  Beauchemin 295; example, 218)
  • Merge()
    • Here's the on-line Help again:  "Merges a specified DataSet,  DataTable,  or array of DataRow objects into the current DataSet or DataTable."
    • There are issues here concerning differences in the DataSet tables:  what if the incoming table has an extra column?   (The statement is written as  dataSet1.Merge(dataSet2),  where  dataSet2  is the incoming one.)  

      You can specify what to do during the  Merge()  operation by using the  MissingSchemaAction,  whose values are  Add, AddWithKey, Error, Ignore.   (Here,  AddWithKey  means to add primary key information into the schema.)   (Help: "DataSet.Merge method";  Beauchemin 152, 217-218)

  • Clear().  This method removes all DataRows from all DataTables,  but leaves the schema intact.   (Help: "DataSet class";  "DataSet.Reset";  "DataSet.Clear")
  • Reset().   The on-line Help says, "Resets the DataTable [or DataSet] to its original state,"  meaning the state at its creation.   If this command is used for a DataSet,  the DataSet is bare;  it doesn't even have a schema.   (Help: "DataSet.Reset";  "DataTable.Reset")
• DataTable  members  
  • Just what exactly does  DataTable  think a Primary Key is?—that is,  how does  DataTable  hold it?   It requires an array of columns,  even if there's only one.   Here's Beauchemin's code:

              //Assuming a DataTable dt, with column "id"
            DataColumn[] adc = new DataColumn[1];
            adc[0] = dt.Columns["id"];
            dt.PrimaryKey = adc;

    (Help: "DataTable.PrimaryKey property";  Beauchemin 139-140)
  • The  Clear()  and    Reset()  methods can also be performed on a DataTable;  see the previous section.

• DataRelation  objects.   See the example in the chapter 5  (Data Binding)  code for reading databases.)
• DataRow  members:
  • BeginEdit(),  EndEdit(),  CancelEdit()  with regard to editing and constraints.   (Help: "DataRow class, all members";  Beauchemin 151-152)
    • The  BeginEdit()  method puts you in edit mode, which suspends referential and other constraints so that you can proceed with the editing.   You have to call it for every DataRow involved.
    • CancelEdit()  undoes your edits for a single row and ends edit mode.
    • EndEdit()  ends edit mode and restores constraint checking.   It will throw an Exception if you have violated the tables' constraints.   But it does not do the same thing as  AcceptChanges();  see below.
  • BeginEdit(),  EndEdit(),  CancelEdit()  with regard to DataRow versions.   The rules are summarized below.   (Help: "DataRow.AcceptChanges Method";  Beauchemin 155-156)
  • DataRow.RowState  and its enumeration,  DataRowState.   This is what the DataAdapter's  Update()  method uses to decide what to do about the row.   (Help: "DataRowState enumeration";  "DataRow class, all members";  Beauchemin 154ff)

    You must distinguish these state values from the versions listed under "DataRows",  below.

    You must distinguish DataRowState from the DataViewRowState enumeration tabulated farther down this page.   (Beauchemin 155)

    Here's something I found in the on-line help:

    Each DataRow object has a RowState property that you can examine to determine the current state of the row.   The following table gives a brief description of each DataRowState enumeration value.

    DataRowState	Description
    Unchanged	No changes have been made since the last call to AcceptChanges or since the row was created by DataAdapter.Fill.
    Added	The row has been added to the table,  but AcceptChanges has not been called.
    Modified	Some element of the row has been changed.
    Deleted	The row has been deleted from a table and AcceptChanges has not been called.
    Detached	Detached is set for a row that has been created but is not part of any DataRowCollection. The RowState of a newly created row is set to Detached. After the new DataRow is added to the DataRowCollection by calling the Add method,  the value of the RowState property is set to Added.   Detached is also set for a row that has been removed from a DataRowCollection using the Remove method,  or by the Delete method followed by the AcceptChanges method.

  • The  DataRowVersion  enumeration.   (Help: "DataRow class, all members";  Beauchemin 155)
    Here's another table lifted from the on-line Help,  under "DataRowVersion Enumeration":

    DataRowVersion	Description
    Current	The row contains current values.
    Default	The default version for the current DataRowState. For a DataRowState value of Added,  Modified or Current, the default version is Current. For a DataRowState of Deleted, the version is Original. For a DataRowState value of Detached,  the version is Proposed.
    Original	The row contains its original values.
    Proposed	The row contains a proposed value.

  • The Rules.   Here's a list from the on-line Help,  just under the previous table:

    The DataRowVersion informs you what version of a DataRow exists.   Versions change under the following circumstances:

    • After calling the DataRow object's BeginEdit method,  if you change the value,  the Current and Proposed values become available.
    • After calling the DataRow object's CancelEdit method,  the Proposed value is deleted.
    • After calling the DataRow object's EndEdit method,  the Proposed value becomes the Current value.
    • After calling the DataRow object's AcceptChanges method,  the Original value becomes identical to the Current value.
    • After calling the DataTable object's AcceptChanges method,  the Original value becomes identical to the Current value.
    • After calling the DataRow object's RejectChanges method,  the Proposed value is discarded,  and the version uses Current.

  • The  DataRow.HasVersion(DataRowVersion.---)  method returns a boolean which tells you whether a DataRow has a specific DataRowVersion.   (A DataRow does not have a "Version" property.   HasVersion  is the way you find out about a DataRow's versions.)   You want to do this because you will get an Exception if you try to process a Version that the DataRow doesn't happen to have.   (Help: "DataRow class, all members", then select "hasVersion" or "DataRowVersion enumeration";   Beauchemin 155)
  • Accessing a DataRow using its  Version.   Here are a couple of lines from the on-line help,  which show how to address one cell in one version of one DataRow:

              DataRow custRow = custTable.Rows[0];
            string custID
              = custRow["CustomerID", DataRowVersion.Original].ToString();

    (I can't find a way of retrieving the entire row according to its Version.   The DataTable.Rows collection doesn't seem to have an indexer that includes a Version specification.)   (Help: "Row States and Row Versions"  in the .NET Framework Developer's Guide;  "DataRow.Item Property (String, DataRowVersion)"
• The  AcceptChanges()  and  RejectChanges()  commands
  • What they do and when you use them.   See  "The Rules"  under  "DataRow members",  above.   (Help: "DataRow.AcceptChanges Method";  Beauchemin 152, 155)
  • What class are they members of?   DataRow,  of course,  but also DataTable and DataSet.
    RejectChanges()  also occurs in all three classes.   (ditto)
  • AcceptChanges()  causes the DataSet to mark all changed DataRows as "Original".   (Help: "DataRow.AcceptChanges method";  Beauchemin 152, 155)
  • RejectChanges()  causes the DataSet to revert to its state at the previous  AcceptChanges()  command,  or just after the DataSet was Filled.   (Help: "DataRow.RejectChanges method";  Beauchemin 152, 155)
  • The relation between  AcceptChanges()  and the  Fill()  command:  Fill()  automatically calls  AcceptChanges()  after populating the DataSet.   (Help: "DataRow.AcceptChanges Method";  "DataAdapter.Fill method";  Beauchemin 183)
  • The relation between  AcceptChanges()  and the  Update()   command:  The on-line Help says,  "After a row updates successfully,  the changes to that row are accepted."   (Help: "DataRow.AcceptChanges Method";  "DataAdapter.Update method";  Beauchemin 212-213)
    In any case,  you must not call  AcceptChanges()  before you do an  Update(),  or you will lose the information on the current state of the rows.   (Stoecker 316)
  • The relation between  AcceptChanges()  and  RowState  and  RowStateFilter:   See the  DataRow.RowState  enumeration,  above.   (Help: "DataRow.RowState property";  Beauchemin 154ff, 249-250)
• DataSet.GetChanges().   The on-line help says,  "Gets a copy of the DataSet containing all changes made to it since it was last loaded, or since  AcceptChanges()  was called."   (That is,  it creates a new DataSet.)   Also useful in connection with DiffGrams;  see below under "XML".   (Help: "DataSet.GetChanges method")
• The  Update()  command.   Here are a couple of paragraphs from the on-line Help: 
  • "When an application calls the Update method,  the DataAdapter examines the RowState property,  and executes the required  INSERT,  UPDATE,  or  DELETE  statements iteratively for each row,  based on the order of the indexes configured in the DataSet.   For example,  Update might execute a DELETE statement,  followed by an INSERT statement,  and then another DELETE statement,  due to the ordering of the rows in the DataTable.  

    "It should be noted that these statements are not performed as a batch process;  each row is updated individually.   An application can call the GetChanges method in situations where you must control the sequence of statement types  (for example,  INSERTs before UPDATEs).   For more information,  see Updating the Database with a DataAdapter and the DataSet."     (Help: "DataAdapter.Update method")

• Finally,  to summarize some of these items,  here is something from on-line Help:

  In a typical multiple-tier implementation,  the steps for creating and refreshing a DataSet,  and in turn,  updating the original data are to

  1. Build and fill each DataTable in a DataSet with data from a data source using a DataAdapter.
  2. Change the data in individual DataTable objects by adding,  updating,  or deleting DataRow objects.
  3. Invoke the  GetChanges  method to create a second DataSet that features only the changes to the data.
  4. Call the  Update  method of the DataAdapter,  passing the second DataSet as an argument.
  5. Invoke the  Merge  method to merge the changes from the second DataSet into the first.
  6. Invoke the  AcceptChanges  on the DataSet.   Alternatively,  invoke  RejectChanges  to cancel the changes.     (Help: "DataSet class")

  [I should point out that you don't have to do it this way.   The  Update  method will examine the RowState of each DataRow and,  if there's no change,  will not change that row in the external database.   You don't have to create a second DataSet with  GetChanges  if you don't want to.]

DataViews

• The differences between Views on the server and DataViews on the local machine   c(Help: "views-SQL Server, overview";  "views in DataTable")
• DefaultView   (Help: "views in DataTable", then select "Sorting and Filtering Data Using a DataView"; "data views, about data views";  Beauchemin 42-45, 246ff)   
  • Each DataTable has a  DefaultView  property.   You don't have to create this View.   Also,  don't think of this View as a container external to the table.
  • The following example is lifted from Beauchemin's page 43.   Note that although you find the row to update by using the DefaultView,  you index the row in the table directly;  you don't have to go through the DefaultView:

              //Have a "Products" table in DataSet ds.  Tell the DefaultView
            //which column is the sort key, which will be used for "Find".
            //We don't have to create this DefaultView first.
    
            ds.Tables["Products"].DefaultView.Sort = "ProductID";
    
            //Find a row to change, using the Default View.  The integer
            //returned is the index in the original table, not in the view
    
            int i = ds.Tables["Products"].DefaultView.Find("123");
    
            //Change the value of the column in the row found by DefaultView.Find--
            //but "DefaultView" does not appear in this next statement
    
            ds.Tables["Products"].Rows[i]["Color"] = "mediumblue";

• Some properties of a DataView   (Help: ditto;  Beauchemin 246ff, 42-45)
  • Sort:  the sort key
  • ApplyDefaultSort:  uses the table's primary key.   It works only if the Sort  property is null or an empty string.     (Beauchemin 246)
  • RowFilter:  based on the values in the row
  • RowStateFilter:  uses the values of the  DataViewRowState  enumeration,  tabulated below.   You must distinguish these state values from the RowState listed under "DataRows",  above.

    Here's an example of using the DataViewRowState in a statement:    (Beauchemin 250)

            ds.Tables["Products"].DefaultView.RowStateFilter
              == DataViewRowState.ModifiedCurrent;

    The following table,  lifted from the on-line Help,  shows the options for DataViewRowState.   Uh-oh.

    DataViewRowState	Description
    CurrentRows	The Current row version of all Unchanged, Added,  and Modified rows. This is the default.
    Added	The Current row version of all Added rows.
    Deleted	The Original row version of all Deleted rows.
    ModifiedCurrent	The Current row version of all Modified rows.
    ModifiedOriginal	The Original row version of all Modified rows.
    None	No rows.
    OriginalRows	The Original row version of all Unchanged, Modified,  and Deleted rows.
    Unchanged	The Current row version of all Unchanged rows.

    Now the question is, What exactly is the difference between RowState and DataViewRowState?

    Well,  first,  they are used differently.   The DataViewRowState is used in a DataTable.Select statement,  which results in an array of DataRows,  which is not quite bindable:  it won't give you an Exception,  but it won't give you useful data,  either.   The DataViewRowState is also used in the DataView's own RowFilter specification,  which results in a fully bindable DataSet.

    The RowState is used by the DataAdapter's Update() method to decide how to handle each row that must be sent to the external database.   (Help: "Update method")

    The RowState can also be used  (as the DataViewRowState cannot)  as an argument to the  GetChanges()  method,  as discussed above.

    This is still a frustrating question,  though,  in two ways:  first,  nobody talks about it clearly,  though lots of sources mention both of them;  and second,  nobody explains why we need both of them.  

• If we get to it  (hah!),  how to update a database using Views.  
  • You can update through a DataView on the local machine,  but you can also prevent this by setting properties on the DataView.   Remember that you use a DataView to sort or to find a row,  but the DataAdapter's  Fill()  method works on the DataTable,  not the DataView.   DataViews do not hold their own version of DataRows.
  • You can also update using a View on the Server,  but there are restrictions here,  too,  such as the difficulty of updating if two tables are JOINed in the View.

DataSets and XML

• The correspondence between the DataSet's DataSetName property and the root node of the XML document.   "A name for the DataSet is required to ensure that the XML representation of the DataSet always has a name for the document element,  which is the highest level element in a schema definition."   (This is really hard to find out.   The quotation is from the on-line Help page titled  "DataSet Constructor (String)",  which page name,  however,  is not indexed.   To find it, you have to use Help's Search window.)
• Reading XML into a DataSet:
  • The  DataSet.ReadXml()  command
    • How does the command differ from other commands that read XML, such as  XmlTextReader, XmlDocument.Load(),  and  XmlDocument.LoadXml()?   Those methods don't deal directly with a DataSet.
    • The  ReadXml()  command's arguments:   (Help: "ReadXml method";  Beauchemin 283-288)
      1. (required):  the Stream,  file name,  TextReader,  or XmlReader  to read from.
      2. (optional):  XmlReadMode:  what to read and how to read it—
  • The  XmlReadMode  enumeration.   (Help: "XmlReadMode enumeration";  in the .NET Framework Class Library;  Beauchemin 285-286)

    The following table is lifted from the on-line help.   For what a DiffGram might be,  see under "Writing XML from a DataSet,  below.

    XmlReadMode	Description
    Auto	Default.   Performs the most appropriate of these actions: If the data is a DiffGram,  sets XmlReadMode to DiffGram.   -or- If the dataset already has a schema,  or the document contains an in-line schema,  sets XmlReadMode to ReadSchema.   -or- If the dataset does not already have a schema and the document does not contain an in-line schema,  sets XmlReadMode to InferSchema.
    DiffGram	Reads a DiffGram,  applying changes from the DiffGram to the DataSet.   The semantics are identical to those of a Merge operation.   As with the Merge operation,  RowState values are preserved.   Input to ReadXml with DiffGrams should only be obtained using the output from WriteXml as a DiffGram.   The target DataSet must have the same schema as the DataSet on which WriteXml as DiffGram is called.   Otherwise the DiffGram merge operation fails,  and an exception is thrown.
    Fragment	Reads XML documents,  such as those generated by executing FOR XML queries,  against an instance of SQL Server.   When XmlReadMode is set to Fragment,  the default namespace is read as the inline schema.
    IgnoreSchema	Ignores any inline schema and reads data into the existing DataSet schema.   If any data does not match the existing schema,  it is discarded (including data from differing namespaces defined for the DataSet).   If the data is a DiffGram,  IgnoreSchema has the same functionality as DiffGram.
    InferSchema	Ignores any inline schema,  infers schema from the data and loads the data.   If the DataSet already contains a schema,  the current schema is extended by adding new tables or adding columns to existing tables.   An exception is thrown if the inferred table already exists but with a different namespace,  or if any of the inferred columns conflict with existing columns.
    ReadSchema	Reads any inline schema and loads the data.   If the DataSet already contains schema,  new tables may be added to the schema,  but an exception is thrown if any tables in the inline schema already exist in the DataSet.

  • ReadXmlSchema().   (Don't confuse this with the preceding XmlReadMode member.)   It  "reads an XML schema into the DataSet"  from the specified source:  Stream, file, TextReader, XMLReader.   (Help: "DataSet.ReadXmlSchema method";  Beauchemin 288;  example,  Kalani 535,  Beauchemin 61)
  • The difference between  ReadXml()  and  DataAdapter.Fill()  in regard to  AcceptChanges().   Beauchemin:  Fill()  implicitly calls  AcceptChanges()  (though this can be overridden),  whereas  ReadXml()  does not;  the changes will not be accepted as "original" until  AcceptChanges()  is explicitly called.   (Help: "reading XML, about reading XML", etc.;  Beauchemin 286)
  • The  XmlValidatingReader   (Help: "XmlValidatingReader class, about XmlValidatingReaderclass";  "Validating XML with XmlValidatingReader"  and other entries under "XmlValidatingReader class";  Beauchemin 48)  
    • Compares the layout of an XML file against its schema.
    • Inherits from the abstract XmlReader class.  
    • Uses  XmlTextReader  as input.
    • Uses the  XmlValidatingReader.ValidationEventHandler  to return an  XmlSchemaException  with information about the problem. (Help: "XmlValidatingReader.ValidationEventHandler Event";   "XmlSchemaException class, about XmlSchemaException class")
• Writing XML from a DataSet:
  • The  WriteXml()  command.   It "writes the current data, and optionally the schema,  for the DataSet."   (Help: "DataSet.WriteXml method";  Beauchemin 292-293)   The command's arguments:
    1. (required):  the Stream,  file name,  TextWriter,  or XmlWriter  to write to.
    2. (optional):  XmlWriteMode:  what to write and how to write it—
  • The  XmlWriteMode  enumeration.   (Help: "XmlWriteMode enumeration";  "DiffGrams";  Beauchemin 293)

    This table is from the on-line help:

    XmlWriteMode	Description
    DiffGram	Writes the entire DataSet as a DiffGram,  including original and current values.   To generate a DiffGram containing only changed values,  call  GetChanges,  and then call  WriteXml  as a DiffGram on the returned DataSet.... When a DataSet is written as a DiffGram,  it populates the DiffGram with all the necessary information to accurately recreate the contents,  though not the schema,  of the DataSet,  including column values from both the Original and Current row versions,  row error information,  and row order.
    IgnoreSchema	Writes the current contents of the DataSet as XML data,  without an XSD schema.   If no data is loaded into the DataSet,  nothing is written.   This is the default.
    WriteSchema	Writes the current contents of the DataSet as XML data with the relational structure as inline XSD schema.   If the DataSet has only a schema with no data,  only the inline schema is written.   If the DataSet does not have a current schema,  nothing is written. [Careful.   If there's no schema,  you still get some XML,  though you don't get a schema.   It's not true that absolutely nothing is written.]

  • More about what a DiffGram is and what it contains:  "DiffGram format is an XML representation of an entire DataSet with extra rows that correspond to pending changes."   For changed rows,  it contains both the original and the new version,   plus "a set of error elements that contains errors for specific rows."   (Beauchemin)   (Help: "DiffGrams" in the .NET Framework Developer's Guide; Beauchemin 284ff;  293-295)
  • WriteXmlSchema()  "Writes the DataSet structure as an XML schema"  onto the specified output:  Stream, file, TextWriter, XMLWriter.   (Help: "WriteXmlSchema method";  Beauchemin 288;  example,  Beauchemin 61)   This method writes out  only  the schema.   Distinguish it from

            dataSet.WriteXML("XMLOutputFileName", XmlWriteMode.WriteSchema);

    which writes out the schema  and  the XML data in the same file.
  • On the other hand,  XmlWriteMode.IgnoreSchema  writes out the XML data with no schema.   (Help: "XmlWriteMode enumeration";  Beauchemin 285-286)
  • Mappings in writing XML.   The tables and columns in the database don't have to look exactly like those in the DataSet.   Here's how you allow differences:
    • DataAdapter.TableMappings, DataTableMapping, DataTableMappingCollection.   These map from a table name in the external database to a DataTable name in the DataSet.   (Help: "TableMapping";  Beauchemin 186-187)
    • DataAdapter.TableMappings.ColumnMappings, ColumnMapping, DataColumnMappingCollection.   These map from a column name in the external database table to a DataColumn name in the DataTable in the DataSet.   (Help: "DataColumn.ColumnMapping property";  Beauchemin 186-187)
    • The  MappingType  enumeration "Specifies how a DataColumn is mapped"  when set for a DataColumn.DataMapping property.   (Help: "MappingType enumeration")

      Here is one last table from the on-line Help:

      MappingType	Description
      Attribute	The column is mapped to an XML attribute.
      Element	The column is mapped to an XML element.
      Hidden	The column is mapped to an internal structure.
      SimpleContent	The column is mapped to an XmlText node.

Though you don't have to memorize the details on this web page,  I cannot emphasize too much the importance of your mastery of this chapter's subject matter.   It supplies more exam questions than any other subject—in fact,  the first dozen or so questions on the exam all seemed to me to be Awful Examples of these issues.   If you're not confident of your knowledge of this stuff,  you are going to have a dreadful experience on the test.

The questions relevant to week two from the questions at the end of this chapter in short Kalani are  6,  8,  10.

• Question 8 is pretty awful:  just what is an "XmlNode"?   Doesn't it include items inheriting from "XmlNode"?

The questions relevant to this week from the two tests at the end of short Kalani are

For flat files and XML—i.e.,  before the additional material:

    Test 1:  none.

    Test 2:  questions  44  (page 426;  answer:  page 447),  46,  48.

The surprise is that short Kalani has all these questions relevant only after the additional material:

    Test 1:  questions  4  (page 351;  answer:  page 389),  5,  6,  10,  11,  12,  13,  17.

    Test 2:  questions  4  (page 404;  answer:  page 439),  8,  37,  39,  49,  51.

(Some of these questions may duplicate those in long Kalani.   Both texts are listed here.)