开发人员从SQL Server 6.5升级到SQL
Server 7.0应该注意哪些问题？
对于一般帐号来说升级程序工作得非常棒。在升级到SQL Server 7.0过程中，SQL
Server 6.5中的别名被转换成角色成员。例如，如果你的一个别名是“dbo”，
SQL Server将把你作为“db_owner”固定服务器角色中的成员。如果你有数个登录名别名是“sales”，
SQL Server 7.0升级程序将创建一个“sales”角色，并为这些用户创建帐号，然后把他们都放入到“sales”角色中。SQL
Server 6.5中的“sales”帐号所拥有的权限中被分配给SQL Server 7.0中的“sales”角色。升级过程中SQL
Server还清理系统权限的模式位，以消除重复的权限。
比较困难的情况是有人可能会把来自不同机器的10个数据库恢复到单个的SQL
Server中，然后再升级。在SQL Server 6.5中，用户帐号必须匹配master数据库中的“syslogins”系统表和每个数据库中的“sysusers”系统表。不幸的是，当你在SQL
Server 6.5中恢复来自其他服务器的数据库时，它们不能够匹配。当这种情况下数据库被恢复后，其安全系统已经损坏，升级到SQL
Server 7.0后仍然是损坏的。
诀窍是在升级前保证你的SQL Server 6.5系统是工作良好的。升级前你还应该运行“sp_change_users_login”系统存储过程来确保数据库用户和登录名存在正确的映射关系。
使用SQL Server 7.0建立一个安全的数据库的最好方法是什么？
永远不要给用户直接访问表的权限。如果你希望让用户使用交互式工具如Microsoft
Acess 2000来访问数据库，可以只给他们访问视图和存储过程的权限，而不是对表的直接访问权限。如果存储过程的拥有者是“dbo”，而且存储过程所引用的表和视图的拥有者也都是“dbo”，给予用户对存储过程的执行（EXECUTE）权限就足够了。这样就根本不用检查对表的访问权限了。
你还可以使用其它安全特性，比如通过在存储过程中加入商业逻辑来控制哪些字段或行能够被访问。视图是阻止用户直接访问表的另一种途径。与存储过程的区别是，你可以为视图授予SELECT、INSERT、UPDATE或DELETE权限，而存储过程则只能授予EXECUTE权限。
还有一件需要注意的事情是，如果你在另外一个数据库中执行SELECT语句，数据库对象拥有者的的链式关系仍然适用。比如说，在由SQL
Server登录名“sa”所拥有的pubs数据库中，你就不能执行跨表查询连接至被一个NT登录名所拥有的数据库中，即使两个登录名都是“sysadmin”角色的成员。如果你希望连接来自3个不同数据库的表，那么这3个数据库的拥有者应该是同一个帐号。如果需要的话你可以使用存储过程“sp_changedbowner”来改变数据库的拥有者。
