Updating, or changing data, is often more difficult than deleting data because of the need to validate the data. For example, in the Students table, the FirstName and LastName fields may be no longer than 20 characters and may not be null. You have your choice about where to enforce data validity; you can check it on the client, on the server, and in the database itself. In my opinion, you should validate the data in all three places, for the following reasons:
■ It's best to validate data as close to the user as possible because it improves both the application's responsiveness and the interface; therefore, you should validate data on the client.
■ A programmer might call your page from a different location, sending unvalidated data; therefore, you should also validate data on the server.
■ Another programmer might use your stored procedures to insert or update data; therefore, you should always validate data in the stored procedures themselves.
Because this example uses dynamic SQL, I'm not going to show you the T-SQL code to validate the data. In addition, to simplify the example, I'm not going to add Validation controls to validate the data on the client, because you've already seen examples of those. Instead, I'll write a little code to perform the validation on the server.
In this case, it's difficult to determine programmatically that a set of characters submitted by a user is not a valid name, but you can check a few things. For example, you can ensure the following:
■ That the names submitted aren't null
■ That they don't contain spaces
■ That they are at least two characters long
■ That they don't exceed 20 characters
■ That they don't contain numbers or other non-alphabetic characters
■ That they begin with a capital letter
The Web Form chl4-8.aspx has most of the functionality of the Web Form chl4-7.aspx, but the controls are slightly rearranged. Clicking a name doesn't just display the name on the server; instead, the Web Form places the name in a TextBox control so that the user can edit the selected name. The Web Form tracks the studentiD of the selected student by placing it in a Label control named lblStudentID. The controls to edit the name are invisible (Visibility=false) until the user selects a name (see Figure 14.13).
Figure 14.13: The Web Form ch14-8.aspx editing a student name
After the user edits the name and clicks the Update Name button, the server validates the data. If the data passes validation, an updateStudent method updates the database, hides the edit controls, and redisplays the updated list.
Warning Be sure to define the cascading delete relationship in the database before running the ch14-8.aspx example; otherwise, you'll get an error if you try to use cascading deletes to delete a student. See the section "Deleting Data Using Cascading Delete Relationships," earlier in this chapter for more information.
Listing 14.7 shows the routines that handle displaying and updating the student name.
Was this article helpful?