Free ASP Scripts, PHP Scripts, Java Scripts, Tools and Utilities

ASP 4Guys from Rolla

Retrieving the Just-Inserted ID of an IDENTITY Column Using a SqlDataSource Control - 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 <code>IDENTITY</code> column. (An <code>IDENTITY</code> 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. <code>IDENTITY</code> 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 <code>EditRecord.aspx?ID=justInsertedRecordID</code>. 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 <code>INSERT</code> statement. Read on to learn more! <a href="http://aspnet.4guysfromrolla.com/articles/100108-1.aspx" class="readmore">Read More ></a>

Programmatically Retrieving a Stored Procedure's Parameters - <a href="http://www.4guysfromrolla.com/webtech/111499-1.shtml">Stored procedures</a> 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 <a href="http://en.wikipedia.org/wiki/Don%27t_repeat_yourself">DRY principle</a> (Don't Repeat Yourself). But the similarities don't end there. The .NET Framework has a feature called <a href="http://msdn.microsoft.com/en-us/library/f7ykdhsy.aspx">Reflection</a> 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 <a href="http://www.codesmithtools.com/">CodeSmith</a> and the <a href="http://www.asp.net/learn/data-access/tutorial-01-vb.aspx">Typed DataSet feature</a> 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! <a href="http://aspnet.4guysfromrolla.com/articles/092408-1.aspx" class="readmore">Read More ></a>

Using ASP.NET 3.5's ListView and DataPager Controls: Grouping By a Data Field - The ListView control renders its <code>ItemTemplate</code> once for every item in its <code>DataSource</code>. As discussed in <a href="http://aspnet.4guysfromrolla.com/articles/010208-1.aspx">Grouping Data with the ListView Control</a> 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. <center><img src="http://aspnet.4guysfromrolla.com/images/ListView/05.01.png" border="0" width="444" height="316" alt="Products, grouped by suppliers and displayed in a patriotic hue." /></center> 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! <a href="http://aspnet.4guysfromrolla.com/articles/091708-1.aspx" class="readmore">Read More ></a>

Creating a Dynamic Data-Driven User Interface (Part 4) - 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 - <code>FirstName</code>, <code>LastName</code>, <code>Email</code>, 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. <a href="http://aspnet.4guysfromrolla.com/articles/082008-1.aspx">Part 1</a> examined the scope of the project and created the data model. <a href="http://aspnet.4guysfromrolla.com/articles/082708-1.aspx">Part 2</a> showed how to allow customers (law firms) to define their custom client attributes. And <a href="http://aspnet.4guysfromrolla.com/articles/090308-1.aspx">Part 3</a> 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! <a href="http://aspnet.4guysfromrolla.com/articles/091008-1.aspx" class="readmore">Read More ></a>

Creating a Dynamic Data-Driven User Interface (Part 3) - 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 <code>Clients</code> table that defines the fixed attributes for a client - <code>ClientId</code>, <code>CustomerId</code>, <code>FirstName</code>, <code>LastName</code>, 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 <code>DynamicAttributesForClients</code>. <a href="http://aspnet.4guysfromrolla.com/articles/082008-1.aspx">Part 1</a> examined the scope of the project and created the data model, while <a href="http://aspnet.4guysfromrolla.com/articles/082708-1.aspx">Part 2</a> 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! <a href="http://aspnet.4guysfromrolla.com/articles/090308-1.aspx" class="readmore">Read More ></a>

Creating a Dynamic Data-Driven User Interface (Part 2) - 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 <code>Clients</code> table contains the fixed attributes for a client and is composed of columns like <code>ClientId</code>, <code>CustomerId</code>, <code>FirstName</code>, and <code>LastName</code>. 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 <code>DynamicAttributesForClients</code>. <a href="http://aspnet.4guysfromrolla.com/articles/082008-1.aspx">Part 1</a> 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! <a href="http://aspnet.4guysfromrolla.com/articles/082708-1.aspx" class="readmore">Read More ></a>

Creating a Dynamic Data-Driven User Interface (Part 1) - Most data-driven web applications have a fixed data model and user interface. What I mean by "fixed" it that the data it needs to be captured is known in advance. Consequently, the database's tables are created before a single line of code is written and the application's user interfaces are dictated by this pre-determined data model. While most applications work with a fixed data model there are scenarios where the parts of the data model need to be defined by the end user. Such applications are more difficult to create because both the data model and user interface need to be flexible enough to allow the user to specify the information to be captured. Imagine that you were creating a web application to be used by small law firms for managing their clientele. You would need a database table to capture information about each client. This table would have columns for each attribute of a client, such as: <code>FirstName</code>, <code>LastName</code>, <code>Email</code>, <code>Address1</code>, <code>Address2</code>, <code>City</code>, and so on. Regardless of what attributes you define for this table you can be certain that there will be a law firm that needs to store additional information not already captured. To allow for this level of flexibility you could enable each law firm to define additional client-related attributes specific to their law firm. This article is the first in a four-part series of articles examine how to build a data model and user interface to allow for such dynamic, data-driven websites. In this installment we look at how to capture such dynamic, end user-defined information in the database. Read on to learn more! <a href="http://aspnet.4guysfromrolla.com/articles/082008-1.aspx" class="readmore">Read More ></a>