For example, you can set Extended Properties to indicate minimum, maximum, suggested, default, mask, description, caption, font, color, or anything else you can imagine. These properties can define a virtually unlimited set of criteria for individual database objects such as the table, the view, or (more relevant to this discussion) the table's column. One approach that still makes sense uses Extended Properties that are exposed on all SQL Server objects. Over the years, the Hitchhiker's Guide has discussed ways to manage business rules of all kinds. Data must not only conform to these structures, but also the formatting characters can be stripped or left in place when passed to the Parameter Valueyour datatype must be set to accommodate the chosen approach. While these formatting regimens are different in other cultures or business, every application has to work with one formatting schema or another. For example, in the U.S., Social Security numbers are formatted as 999-99-9999 and phone numbers are formatted as (999) 999-9999.
This way, you can more easily adapt the application to evolving business rules without redeploying.ĭata is often supplied in specially formatted structures.
It's important to separate the criteria that is likely to change from time to time (more or less frequently) from those rules that really never change. For example, while a human's age in years is always a positive value between 0 and 120 (with a few historical or mythical exceptions), if you're working with adults that can fly an airplane, the range is far narrower. These can be considered business criteria, but as often as not, they're simply common-sense rules. Later in this chapter, I illustrate ways to add properties to the TextBox control to validate the datatype and ensure that data provided falls within a specified range.ĭata also needs to be restricted and validated based on a number of other ever-changing criteria, such as minimum and maximum permitted values, precision, scale, and format. This way, if an error occurs, the user can easily change the data to match the criteria.
This means that the TextBox, DataGridView, MaskedEdit, ComboBox, or whatever UI control is used to capture input needs to be programmed to accept only valid data. Since user-provided values are usually the source of incorrect data, it's essential that input (or edited) data be validated for datatype, range, business rules, and "reasonableness" while the user is focused on the input control. Since the TextBox control (a typical source of user input) manages its Text property as a String, the value can be virtually anything, so you'll need some technique to validate the TextBox Text to ensure it conforms to the correct datatype. However, since the Value property is often (usually) reset based on user input or by program logic just before the SqlCommand is executed, it's essential that the supplied input variable datatype match the SqlParameter object's assigned datatype. When a new SqlParameter object is instantiated, the DbType and SqlType are set to the specified value in the constructor and match the datatype of the Value (if it's supplied) or NVarChar if it's not supplied. The challenges we faced and address in this chapter are: Peter and I spent more than a week researching and discussing the best ways to deal with SqlParameter Value validation.
0 kommentar(er)
