这些设计时存储过程已经被更新，以便利用 SQL Server 2000 的一些新特性，尤其是用户自定义函数（UDFs）特性。因此代码变得非常模块化，并且我们还有额外的函数来完成其它任务。
另一个设计时自动化的好处是保证所生成的数以百计的存储过程都有一致的结构和标准的命名规范。在我们的例子中，所有产生的运行时存储过程的名字被格式化为：prApp_TableName_Task，这里Task 可以是 Select、Update 或者 Delete。用于 Customers 和 Orders 表的存储过程如下所示：
prApp_Customers_Delete
prApp_Customers_Insert
prApp_Customers_Select
prApp_Customers_Update
prApp_Orders_Delete
prApp_Orders_Insert
prApp_Orders_Select
prApp_Orders_Update
正如你看到的，这个规范添加大量的组织到数据库中，使任何存储过程都容易定位并使每个过程的名字都是自描述的。开发人员可以快速发现它并创建代码。最重要的是这个项目未来的团队成员将会发现这些代码和存储过程很容易理解和上手。当然，如果你已经使用了一个不同的命名规范，那么只需简单地改变几行代码，你的命名规范便可被替换使用。
这四个设计时存储过程不是一成不变的，而是可以将它作为模版在其它项目中使用。将它们安装到项目数据库中，如果需要，可以修改它们适应特定应用程序的需要。例如，在我们的几个应用程序中，我们增加代码在单独的数据库中维护每次记录被修改的稽核记录。
一个简单例子
开始前，先看一个使用数据库 Northwind 中 Order_Details 表的简单例子（该表的表名是被修改过的，用下划线取代了空格字符）。尽管空格和其它字符在对象名字中被允许使用，但我们推荐使用常规分割符来命名对象，以防止在使用这些自动化存储过程时可能出现的问题，请参见 SQL Server 在线书籍中“Using Identifiers”部分来获得更多信息。
第一个任务是运行这个设计时存储过程，以创建修改 Order_Details 表数据的运行时存储过程：
EXEC pr__SYS_MakeUpdateRecordProc ''''Order_Details''''
运行这个设计时存储过程将产生如 Figure 1 所示的 T-SQL 脚本。当这个 T-SQL 脚本运行时，它为 Order_Details 表创建一个新的 update 存储过程。所有的列被说明为新存储过程的参数，但是注意当其它非主键字段是 update 命令的 SET 语句的一部分时，主键列（OrderID 和 ProductID）是如何在 WHERE 字句中出现的。设计时存储过程检查 Order_Details 表存储在 SQL Server 系统表中的元数据(metadata)，并用这个信息来创建适当的输出脚本，运行后将创建最后的运行时存储过程。
运行后仅仅产生输出，并且不产生新的运行时存储过程。然而，做个简单的修改，设计时存储过程实际上能运行作为最后输出结果的 T-SQL 脚本。为此，我们只运行设计时存储过程，将值1作为一个标志位，用第二个可选择参数传递，并且再次运行：
EXEC pr__SYS_MakeUpdateRecordProc ''''Order_Details'''', 1
这此不仅显示以前那样的输出结果，而且运行这个输出结果，由此创建运行时存储过程。
现在我们来看一下这个创建特定应用程序运行时存储过程的设计时存储过程的代码。
SQL Server 系统表和视图
为了创建设计时存储过程，我们必须知道如何从 SQL Server 的系统表和信息视图中获得表的定义。首先，我们必须找到这些列，并找出哪些是主键，每列支持哪些数据类型，以及列是否允许为空。
 |
Figure 2 查看系统表
了解通过修改注册服务器的属性，SQL Server 企业管理器能使你查看系统表是非常有用的，如 Figure 2 所示。如果你在企业管理器中右键单击服务器名字，并选择“Edit SQL Server Registration properties”，将弹出一个对话框。在对话框的下面，你可以看到一个标有“Show system databases and system objects”的复选框。选中这个选项便打开了系统对象视图，也可以选择关闭来使表的视图看起来更简单和更易读。
