|
How do I… Reject alpha characters in a SQL Server character column?Enforcing your data’s integrity is probably the single most important issue you face when designing a database. Validating user input is one way of keeping bad data from making its way into your analysis and reports. It only takes one piece of bad data to throw everything off. It’s serious business and there are no shortcuts — mistakes, even innocent ones, are just too easy to make. It’s just too easy to enter one too many zeros or enter “6heodore” instead of “Theodore.” Granted, you can’t stop every single mistake at the input stage, but it’s the best place to start. (We are working with SQL Server Express because it’s free and easy to use, but the concept and examples are valid in SQL Server.) |
The sp_lock system stored procedure is a great tool for checking the amount of locking that occurs on your database system. It returns the number and types of locks that are being held by current active SQL Server sessions. One of my previous articles describes how you can use sp_lock to diagnose problems on your SQL Server.
There are, however, a few drawbacks to sp_lock. The results it returns are not very straightforward to the novice DBA. It does a great job showing what session is causing the largest number of locks on the system, but it does not show you much accompanying detail of those objects or sessions. You could create custom scripts to look up that information, but those results tend to be complicated, and the detail is mediocre at best. There were other system tables that you could use to look up lock information, such as syslockinfo, but that detail isn’t all that great either. Another huge drawback is that sp_lock and syslockinfo are deprecated features, so they may not be included in future SQL Server releases. SQL Server 2005 includes new dynamic management views that contain a lot of locking detail and make it easy to correlate locking information to make it much more meaningful.







