Most of the server controls you find in the VWD Toolbox share some common behavior.
Part of this behavior includes the so-called properties that define the data a control can contain and expose.
Each server control has an ID to uniquely identify it in the page, a Runat attribute that is always set to Server to indicate the control should be processed on the server, and a ClientID that contains the client-side ID attribute that will be assigned to the element in the final HTML.

Every web application includes a web.config file that configures fundamental settings.
They are never locked: You can update web.config settings at any point, even while your application is running. If there are any requests currently under way, they will continue to use the old settings, while new requests will get the changed settings right away.
They are easily accessed and replicated: Provided you have the appropriate network rights, you can change a web.config file from a remote computer. You can also copy the web.config file and use it to apply identical settings to another application or another web server that runs the same application.
The settings are easy to edit and understand: The settings in the web.config file are human readable, which means they can be edited and understood without needing a special configuration tool.

VIEWSTATE The hidden form field that is used to transfer the state from the server to the client and back View State The mechanism that enables the controls to store state at the client. 
VIEWSTATE concepts

  • VIEWSTATEis an ASP.NET feature that provides for retaining the values of page and control properties that change from one execution of a page to another.
  • Before ASP.NET sends a page back to the client, it determines what changes the program has made to the properties of the page and its controls. These changes are encoded into a string that is assigned to the value of a hidden input field named C.
  • When the page is posted back to the server, the VIEWSTATE field is sent back to the server along with the HTTP request. Then, ASP.NET retrieves the property values from the VIEWSTATE field and uses them to restore the page and control properties.
  • ASP.NET also uses view state to save the values of the page properties it uses, such as IsPostBack.
  • VIEWSTATE  is not used to restore data entered by a user into a text box or any other input control unless the control responds to change events.
  • If VIEWSTATE  is enabled for a data-bound control, the control will not be rebound when the page is reposted. Instead, the controls values will be restored from view state.

ASP.NET uses session state to track the state of each user of an application. To do that, it creates a session stale object that contains a unique session ID for each users session. This ID is passed back to the browser as part of the response and then turned to the server with the next request. can then use the session ID to get the session state object thats associated with the request.

To create a cookie, you instantiate an object from the HttpCookie class. Then, you include it in the HTTP response that the server sends back to the browser, and the users browser stores the cookie either in its own memory or in a text file on the client machines disk. 
A cookie that stored in the browser memory is called a session cookie because it exists only for that session. When the browser session ends, the contents of any session cookies are lost. Session cookies are what uses to track session IDs. In contrast, persistent cookies are written to disk, so they are maintained after the browser session ends. Whether session or persistent, though, once a cookie is sent to a browser, it is automatically returned to the server with each HTTP request.
Besides using cookies for session IDs, you can use cookies to save information that identifies each user so the users do not have to enter that information each time they visit your web site. You can also use cookies to store information that lets you personalize the web pages that are displayed for a user.
When you use cookies to store this type of information, you should keep in mind that some users may have disabled cookies on their browsers. In that case, you would not be able to save cookies on the users computer. Unfortunately, does not provide a way for you to determine whether a user has disabled cookies. As a result, if you use cookies in an application, you may need to notify the user that cookies must be enabled to use it.

The SqlCommand class is -

  • To execute a SQL statement against a SQL Server database, you create a SqlCommand object that contains the statement. The Connection property of this class associates the command with a SqlConnection object, and the CommandText property contains the SQL statement to be executed.
  • The CommandType property indicates how the command object should interpret the value of the CommandText property. Instead of specifying a SQL statement for the CommandText property, for example, you can specify the name of a stored procedure, which consists of one or more SQL statements that have been compiled and stored with the database.
  • You can execute a command object directly by using one of the three Execute methods show. If, for example, you use ExecuteReader for a Select statement, the results are returned as a DataReader object. If you use ExecuteScalar, only the value in the first column and row of the query results is returned.
  • If the command contains an Insert, Update, or Delete statement, you will use the ExecuteNonQuery method to execute it. This method returns an integer value that indicates the number of rows that were affected by the command. If, for example, the command deletes a single row, the ExecuteNonQuery method returns 1.

The SqlDataReader class
This class is used to create a data reader object, which provides an efficient way to read the rows in a result set returned by a database query. In fact, when you use a data adapter to retrieve data, the data adapter uses a data reader to read through the rows in the result set and store them in a dataset.

  • A SqlConnection object is required to establish a connection to a SQL Server database.
  • A SqlCommand object is used to execute a SQL command against a SQL Server database.
  • A SqlParameter object is used to pass variable information to a SQL command.

The SqlParameter class lets you pass parameter values to a SQL command. Parameters arc commonly used to limit the number of rows retrieved by a Select statement. For example, you can retrieve the Product row for a specific product by passing the ProductlD as a parameter. Or, you can retrieve all of the products for a given category by passing the CategorylD as a parameter. Parameters are also commonly used to pass column values to Insert, Update, and Delete statements.

Aspx code generated for a basic SqlDataSource control
<asp:SqlDataSource ID="SqlDataSourcel" runat="server" ConnectionString="<%$ConnectionStrings:w3aspConnectionString%>"
SelectCommand="SELECT [CategoryID], [LongName] FROM [Categories]
ORDER BY [LongName]">

The web.config file has a connectionStrings element that contains an add element for each connection string. In the example, the connection string is named w3aspConnectionString, and the connection string refers to a database named w3asp on the server named localhost\sqlexpress.

PreviousDisplaying 3 of 3
1 2 3
Need Help? Contact Us.

Log in


Forgot password?


New User