注册
登录
| 关键词： IDENTIFIER SET go dbo create QUOTED function 生成 select NULLS |
微软的SQL脚本生成令我伤透了心——我一直以为是我的程序上的问题，或者我操作上的失误，并且，客服人员屡屡埋怨我的程序bug，多次测试之后，才发现，原来都是微软惹的祸…… Sql Server的脚本生成有不少漏洞，经常由它生成的脚本运行起来会有错误。下面举例说明： 1. 并没有根据sysdenpends的依赖关系生成SQL代码，而是根据所谓的“优先级”来生成。 比如：他认为view的优先级就要比function高。 那么，我写了下面的测试程序，形成如下的依赖关系：fnT1 <-- vwT1 <-- fnT2 就是，view vwT1处于依赖的中间。 create function fnT1() returns Integer as begin return 123 end go create view vwT1 as select aa=dbo.fnT1() go create function fnT2() returns table as return (select * from vwT1) go运行到数据库之后，用Enterprise生成SQL代码。要注意选项不一样，生成的代码会有所不同，在这里我没有选数据库和用户。 if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[fnT1]') and xtype in (N'FN', N'IF', N'TF')) drop function [dbo].[fnT1] GO if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[fnT2]') and xtype in (N'FN', N'IF', N'TF')) drop function [dbo].[fnT2] GO if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[vwT1]') and OBJECTPROPERTY(id, N'IsView') = 1) drop view [dbo].[vwT1] GO SET QUOTED_IDENTIFIER ON GO SET ANSI_NULLS ON GO Create view vwT1 As Select aa=dbo.fnT1() GO SET QUOTED_IDENTIFIER OFF GO SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO SET ANSI_NULLS ON GO Create function fnT1() Returns Integer As begin Return 123 end GO SET QUOTED_IDENTIFIER OFF GO SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO SET ANSI_NULLS ON GO Create function fnT2() Returns Table As Return (Select * From vwT1) GO SET QUOTED_IDENTIFIER OFF GO SET ANSI_NULLS ON GO从上面你一眼就可以看出来了，建立view要比建立function先，而不是根据依赖关系建立。毫无疑问，将会得到如下的严重的错误： 服务器: 消息 208，级别 16，状态 1，过程 vwT1，行 4 对象名 'dbo.fnT1' 无效。 服务器: 消息 208，级别 16，状态 1，过程 fnT2，行 5 对象名 'vwT1' 无效。 2. 作业脚本 这个我就不说了，bug还不是很严重，主要是中文“——”注释符的问题。英文版我没有测试过，不过猜想应当没有这个bug，大家可以试试看。 3. 还有一个SP的问题 spGetIDStr和spAnalyseStrList的关系，是后者依赖于前者。可是spGetIDStr我并没有调用任何的表，因此，每当运行SQL Server生成的脚本的时候，总是报告类似这样的信息： spGetIDStr并不存在，无法在sysdepends里建立依赖关系，存储过程spAnalyseStrList仍然建立。无论我手工修改其建立顺序或是别的方面，用它生成的脚本就是有错。这里，再看看第三个bug，看我下面的测试程序： （原理：当sp没有对表或视图等数据库对象有依赖关系时，sp被别的sp引用时也将无法建立依赖关系） 形成依赖关系：spB1 <--- spA1 create proc spB1 as return 11 go create proc spA1 as begin declare @i int exec @i=spB1 return @i*2 end go生成的脚本就为： if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[spA1]') and OBJECTPROPERTY(id, N'IsProcedure') = 1) drop procedure [dbo].[spA1] GO if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[spB1]') and OBJECTPROPERTY(id, N'IsProcedure') = 1) drop procedure [dbo].[spB1] GO SET QUOTED_IDENTIFIER ON GO SET ANSI_NULLS ON GO Create proc spA1 As Begin Declare @i int Exec @i=spB1 Return @i*2 End GO SET QUOTED_IDENTIFIER OFF GO SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO SET ANSI_NULLS ON GO Create Proc spB1 As Return 11 GO SET QUOTED_IDENTIFIER OFF GO SET ANSI_NULLS ON GO现在，大家应当明白我故意命名为spA1，spB1缘故了。因为如果没有依赖关系的话，A自然排在B前面，你看微软可不就是这么做的么？幸好这个bug还不是很大，怎么说SP还是建立了起来。 各位有兴趣的可以试试别的，比如sp与fn，sp Group等等。 |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
