WebOcreation, Rupak Nepali, OpenCart, Drupal Developer, Agile Development

AcceptChanges and RejectChanges The AcceptChanges( ) and RejectChanges( ) methods either accept or reject the changes that have been made to the DataSet since it was last loaded from the data source or since AcceptChanges( ) was last called. The AcceptChanges( ) method commits all pending changes within the DataSet . Calling AcceptChanges( ) changes the RowState of Added and Modified rows to Unchanged . Deleted rows are removed. The Original values for the DataRow are set to the Current values. Calling the AcceptChanges( ) method has no effect on the data in the underlying data source. The AcceptChanges( ) method is implicitly called on a row when the DataAdapter successfully updates that row back to the data source when the Update( ) method is called. As a result, when a DataAdapter is used to update the data source with the changes made to the DataSet , AcceptChanges( ) doesn't need to be called. Calling AcceptChanges( ) o

Adding Custom Information The DataSet contains a PropertyCollection that is exposed through the ExtendedProperties property. This collection allows a user to add custom information to the DataSet such as the date and time when the DataSet should be refreshed. The following example sets an extended property indicating that the DataSet should be refreshed in 20 minutes: ds.ExtendedProperties.Add("RefreshDateTime",     DateTime.Now.AddMinutes(20).ToString()); The following code can then check that value to see if the DataSet needs to be refreshed: if(DateTime.Now>Convert.ToDateTime(     ds.ExtendedProperties["RefreshDateTime"].ToString( ) )) {     // ... code to refresh the DataSet } Extended properties must be of type String , or else they will not persist when the DataSet is written as XML. The DataTable , DataColumn , DataRelation , and Constraint objects also have a similar collection of extended properties. Cloning

Adding and Removing Relations Relations belonging to the DataSet are stored as DataRelation objects in a DataRelationCollection object and are accessed through the Relations property of the DataSet . Each DataRelation object represents the relationship between a parent and child table in the DataSet . This section examines some methods and properties of the DataRelationCollection . Relations are added to the DataSet using the Add( ) method of the DataRelationCollection , as shown in the following example: ds.Relations.Add("MyDataRelation", parentTable.Columns["PrimaryKeyField"],     childTable.Columns["ForeignKeyField"]); The Remove( ) method removes a relation matching the relation-name argument. The following example removes the relation added in the previous example: ds.Relations.Remove("MyDataRelation"); The Contains( ) method can determine if a specific relation exists as shown in the following

Creating an Untyped DataSet There are several ways a DataSet can be created. In the simplest case, a DataSet is created using the new keyword . The constructor accepts on optional argument that allows the DataSetName property to be set. If the DataSetName argument isn't supplied, the default name of the DataSet will be NewDataSet . DataSet ds = new DataSet("MyDataSet"); A DataSet can also be created from another DataSet . The Copy( ) method can create a new DataSet containing both the schema and data from the original DataSet . The Clone( ) method creates a new DataSet with the same schema, but none of the data of the original. Finally, the GetChanges( ) method creates a new DataSet containing data that has changed since the DataSet was last loaded or the pending changes were accepted. Working with Tables in the DataSet Tables belonging to the DataSet are stored as DataTable objects in a DataTableCollection object an

ADO.NET's Disconnected Architecture//theory+program Beside availability of an open connection for the data all of the time which require that applications should connect to the data source, read required data and disconnect the connection, process the data, reconnect and save the changes, we have new disconnected method. Using disconnected RecordSets is tedious with ADO due to marshalling issues. All this was leading to disconnected architecture for quite some time now. We have just seen how to use a Connection object, a Command object and a DataReader to perform database operations. This is good enough when you want to process only one row at a time. In practice however, one needs to process or display multiple rows at a time. In such cases, it is difficult to use the DataReader. Therefore, ADO.NET provides other objects for such operations. These objects are mostly use in a disconnected environment. The DataAdapter Object Data adapters are

The DataReader Class The DataReader object represents a read-only, forward-only stream of data, which is ideal for quickly retrieving query results. The DataReader is useful if you don't need the full support for versioning and change tracking provided by the DataSet . Best of all, because the DataReader loads only a single row into memory at a time, it has a small in-memory footprint. You can't create a DataReader directly. Instead, you must use the ExecuteReader( ) method of a Command object that returns a DataReader . As with all connection-specific objects, there is a DataReader for every data provider. Here are two examples: ·          System.Data.SqlClient.SqlDataReader provides forward-only, read-only access to a SQL Server database (Version 7.0 or later). ·          System.Data.OleDb.OleDbDataReader provides forward-only, read-only access to a data source exposed through an OLE DB provider. Typical DataReader access code f

The connected and disconnected ADO.NET classes   disconnected architecture figure,connected architecture figure

This spread the new folder virus..... Install the new folder virus and then scan the whole computer bywhich you will be able to know how many folder do you have by the formula No. of folders=(threats found-2) Minus 2 for the folder virus itself. Like this way we can find out the folders in our computer...... This is really a good joke-------------------------

Creating and Executing a Command When creating a Command object, you have the choice of several constructors. The most useful accepts a CommandText value and a Connection . Here's an example with the SqlCommand class: SqlConnection con = new SqlConnection(connectionString); SqlCommand cmd = new SqlCommand(commandText, con); For standard providers, there are three ways to execute a command: ExecuteNonQuery( ) , ExecuteReader( ) , and ExecuteScalar( ) . You choose one of these methods, depending on the type of command you are executing. For example, ExecuteReader( ) returns a DataReader and provides read-only access to query results. Some providers include additional members. For example, the ADO.NET SQL Server provider includes an ExecuteXmlReader( ) method that retrieves data as an XML document. Executing a Command That Doesn't Return Rows The SQL language includes several nonquery commands. The best known include UPDATE, DELETE, and

Opening and Closing Connections You've now seen all the ingredients you need to create and use a connection. You simply create the Connection object required for your data source, apply the appropriate connection string settings, and open the connection. In an example below, a connection is created to a SQL Server database on the local computer using integrated authentication. The code opens the connection, tests its state, and closes it. Example. Opening and testing a connection //opining n closing database // ConnectionTest.cs - Opens and verifies a connection   using System; using System.Data.SqlClient;   public class ConnectionTest {     public static void Main ()     {         SqlConnection con = new SqlConnection("Data Source=localhost;" +                "Initial Catalog=Northwind;Integrated Security=SSPI");           con.Open();         Console.WriteLine("Connection is " + con.State.ToString());