AJAX applications offer a more interactive user experience by replacing traditional full page postbacks with leaner and more efficient partial page postbacks. These partial page postbacks are executed asynchronously using JavaScript code in the browser. When a web surfer clicks on a link or submits a form (via a full page postback) the browser automatically adds the page being left to the browser's history. This allows the web surfer to use his Back and Forward buttons to navigate through this history. However, the partial page postbacks performed by AJAX applications do not cause the browser to register anything in their history. As a consequence, if a user visits an AJAX-enabled web page, performs a number of partial page postbacks, and then clicks the Back button, she is not returned to the state of the page prior to the last partial page postback. Instead, she is taken back to the page she was at before arriving at the AJAX-enabled web page.

The good news is that starting with ASP.NET 3.5 SP 1, the ScriptManager control in the ASP.NET AJAX Framework includes functionality for creating history points in an AJAX-enabled web page. Adding a history point creates an entry in the browser's history for a particular page state. What's more, this page state is encoded in the querystring of the browser, meaning that visitors can bookmark a particular state of an AJAX application.

This article shows how to add history points using the ScriptManager control. In particular, it shows how to record history points whenever the user pages or sorts a GridView. Read on to learn more!
Read More >

ASP.NET offers a variety of tools and mechanisms for working with database data, including a number of data source controls, such as the SqlDataSource, ObjectDataSource, and LinqDataSource, among others. The SqlDataSource is one of the most basic data source controls as it operates directly against a configured database. Using the SqlDataSource control, an ASP.NET developer can retrieve, insert, update, or delete data by simply setting a few properties. Little to no code is needed.

While the SqlDataSource makes it a walk in the park to implement the most common data access scenarios, a little extra effort is needed for more intricate scenarios. One such data access pattern is retrieving the value of the just-inserted record's ID field, where the ID field is an IDENTITY column. (An IDENTITY column is a numeric column in a SQL Server database table that has its value automatically assigned when a new record is added to the table. IDENTITY columns are sometimes referred to as auto-number columns, as well.) Being able to get the ID value of the just-inserted record is helpful in cases where you need to insert a new record and then insert other records into related tables, or when you want to let the user start working with the just-added record, which might entail taking them to a URL like EditRecord.aspx?ID=justInsertedRecordID.

This article shows how to use the SqlDataSource control to insert a new record and retrieve the value of its ID field. In particular, we will look at two examples: one that uses a stored procedure to insert the new record and another that uses an ad-hoc INSERT statement. Read on to learn more!
Read More >

Stored procedures in SQL Server are similar to methods in C# and Visual Basic code. They encapsulate one or more statements into a single, parameterized construct. Both stored procedures and methods are a form of code reuse and their use help developers adhere to the DRY principle (Don't Repeat Yourself). But the similarities don't end there. The .NET Framework has a feature called Reflection that enables developers to programmatically retrieve a list of methods for a given class, along with their input parameters and return types. It's also possible to programmatically determine what stored procedures exist in a database, along with each stored procedure's input and output parameters.

Being able to programmatically retrieve a database's stored procedures and determine their parameters are useful in a handful of scenarios. For example, code generators like CodeSmith and the Typed DataSet feature in Visual Studio use these techniques to determine the code to construct to call each stored procedure. These techniques are also useful for allowing ad-hoc stored procedure execution from a page on your website, which can be a useful tool for administrators.

This article shows how to retrieve a list of stored procedures in a database and how to enumerate a selected stored procedure's input and output parameters. We'll also look at how to let the user visiting the page pick a stored procedure, enter values for its parameters, and execute and view the resulting output. Read on to learn more!
Read More >

The ListView control renders its ItemTemplate once for every item in its DataSource. As discussed in Grouping Data with the ListView Control it is possible to inject grouping template every N records. This flexibility allows for scenarios like displaying data in a multi-column table.

While the built-in grouping feature is certainly useful, when it comes to displaying data most people think of grouping to mean that records with similar attributes are lumped together. For instance, the Northwind database contains information about an assortment of products, and each product has attributes like product name, category, supplier, and so forth. While each product name is unique, many products share the same category and supplier. When someone says, "I want to group the product data," usually they mean they want to group it by one of these common attributes. The following screenshot shows the user interface people most people associate with the term grouping. Here products are grouped by supplier.

Unfortunately the ListView's grouping feature does not allow for this style of grouping. The good news is that with a few lines of code and markup we can construct such an interface. This article shows how to build a flexible grouping interface that allows the user to choose what data field to group the data by. Read on to learn more!
Read More >

This article is the fourth and final installment of a series that examines how to build a data-driven web applications that offers dynamic user interfaces. Over the past three articles we created a sample web application that allows for numerous law firms to log in to the site and manage their clientele. Client data is dispursed across fixed and dynamic data models. The fixed data model contains a set of client attributes common to all law firms - FirstName, LastName, Email, and so forth - while the dynamic data model allows each law firm to define their own custom client attributes. For example, a personal injury firm could include attributes like Date Injured, and Was Permanently Disabled, while a law firm specializing in bankruptcy would have attributes like Debt Servicing Cost and Monthly Income Amount.

A completely functional demo was constructed over the past three installments. Part 1 examined the scope of the project and created the data model. Part 2 showed how to allow customers (law firms) to define their custom client attributes. And Part 3 looked at dynamically building the user interface for collecting custom client attributes. While the web application created over the past three tutorials offer a true dynamic, data-drive user interface, there are several places that could be improved upon. This final installment reviews some of these enhancements with a discussion on how to implement each of them. Read on to learn more!
Read More >

This article is the third installment of a four-part series that examines how to build a data-driven web applications that offers dynamic user interfaces. Over the past two articles we created a sample web application that allows for numerous law firms to log in to the site and manage their clientele. The application's data model contains a Clients table that defines the fixed attributes for a client - ClientId, CustomerId, FirstName, LastName, and so on. All law firms have these fixed attributes available to them. Each law firm can also define dynamic attributes. For example, a law firm that specializes in personal injury might need to capture client information like type of injury, whether the injury occurred on a job site, and so forth. The custom client attributes for each law firm are stored in a database table named DynamicAttributesForClients.

Part 1 examined the scope of the project and created the data model, while Part 2 showed how to allow customers (law firms) to define their custom client attributes. In this installment we create the web pages for managing clients. This includes two pages: one page to create new clients and manage their fixed attributes, and a second page to manage their custom attributes. Read on to learn more!
Read More >

This article is the second installment of a four-part series that examines how to build a data-driven web applications that offers dynamic user interfaces. Over the course of this article series we will build a complete and functional web application with a dynamic, data-driven user interface. Specifically, the demo application is a fictional website used by numerous law firms to manage their clientele.

The application uses both a fixed and dynamic data model for law firms to manage their clients. The Clients table contains the fixed attributes for a client and is composed of columns like ClientId, CustomerId, FirstName, and LastName. All law firms have these fixed attributes available to them. The dynamic data model allows each law firm to define custom attributes for their clientele. For example, a law firm that specializes in personal injury might need to capture client information that is not needed for a law firm that specializes in family law. The custom client attributes for each law firm are stored in a database table named DynamicAttributesForClients.

Part 1 examined the scope of the project and created the data model. In this installment we create the web pages used by the law firms to define the custom client attributes. Read on to learn more!
Read More >