工作日志 6/2/2014 - SQL的stored procedure

今天是我生日，今年的生日是在工作中度过的，预示着这一岁的好势头吧！

今天起来fix这个parameterization的问题，按理说，如果用了它，就不该出现‘ unmatched quotes错误， 我就看了一下code，从C#里面看没有太多问题，就是把参数输进去，输进去的string里面带有单引号，到了SQL stored procedure，老头用的是这样的语句：

IF LEN(@NewSiteNameTrim) > 0
              BEGIN
                     SET @sSet = 'SET SiteName = ''' + @NewSiteNameTrim + ''' '
              END

而我之前看的材料都是直接在引号里面加参数的@symbol，用不着再加单引号啊，这不是多此一举嘛，这样出来的结果还是两个单引号啊，不能够escape啊。于是我改成了：

IF LEN(@NewSiteNameTrim) > 0
              BEGIN
                     SET @sSet = 'SET SiteName =  @NewSiteNameTrim  '
              END

把他放到SQL一试，结果不行。。。。。

很奇怪的是，如果是insert 这样的语句，比如：

INSERT INTO vidConfSites 
              (
                     SiteName,
                     AlternateName, 
                     DeliveryMode 
              ) 
              VALUES 
              (
                     @SiteNameTrim, 
                     @AlternateNameTrim,
                     @DeliveryModeTrim 
              )

是可以的，但如果是string 连接，如上边的，只能读出来@newsitenametrim这样的content，并不把它替换成parameter。

可能是它在SQL的stored procedure里面，如果在外面的vb或c#，那应该在后边加一个addParameter（）method添加parameter的内容， 可是不在于是就奇怪了。

这样的解决方法，就是要手动的把单引号替换成两个单引号，这个工作不能在c#或vb外面做，因为insertion还好好的，如果替换了，用户输入的单引号就变成了双引号，不对，所以要在stored procedure里面的各个method里面改，用到了replace(@NewSiteNameTrim,'''','''''')语句，这样在sql测试成功，在外部测试便开始有些奇奇怪怪的input。

debug了半天，原来发现是因为在c#里string本来就被替换了单引号，到了stored procedure会两次替换，这是老头写的code啊，这岂不是坑我，于是我快崩溃了，花了一下午的时间把这个屁股上的屎给擦了，发了testing request邮件，这么个app就算完成。