whidbey 中的sql server project  提供了在vs.net中创建.net sqlserver过程（存储过程、函数、触发器、自定义类型等） 的支持 ，鉴于此功能未见有人报道，可能大部分人都在手动在sql server 查询分析器中键入create assembly等（像我以前一样），所以特地提出来，使大家在测试yukon更容易一些。

New Project时的SQL Server Project

自动引用了Sqlaccess.dll和Microsoft.VisualStudio.DataTools.SqlAttributes.dll

 
add item
 

deply 功能 

SqlAssembly ,SqlFunc,SqlProcedure,SqlTrigger,SqlMapping 等attribute

这些attribute 可以帮助ide 在deply时
确定Assmebly名称
如
Create Assembly testyukon from 'xxxxx'
等价于
[assembly: SqlAssembly("testyukon")]
存储过程
默认的，存储过程的名称是方法名称，你可以使用
[SqlProcedure("newname"]
public void TestProcedure()
{
...
}  

重新指定
对于SqlTrigger ，则有Name,Target,ForClause属性
由于过于简单，所以不一一说明

关于 stinger

在我们都在等待yukon时，ibm已经在db2中引入了clr存储过程支持
代号为 Stinger  DB2 Development Add-In Technical Preview的一些特色得确不错
具体大家可以从dwcn上了解 链接

总有一种与比较yukon的冲动，我非常遗憾的看到，现在db2只支持在存储过程中使用.net assembly，而在 yukon中，支持扩展到自定义函数，存储过程，触发器，自定义数据类型，自定义聚集函数等

stinger引入clr的技术和yukon是相似的，比方说都有一个context对象(yukon是SqlContext而db2是DB2Context)，但返回数据，yukon通过一个SqlPipe来实现，而db2好像就是默认什么都不做，这至少有些令人迷惑

DB2

public static void StoredProcedure1 ()
    {
        DB2Command cmd = DB2Context.GetCommand ();
        cmd.CommandType = CommandType.Text;
        cmd.CommandText = "select * from customer";
       
        DB2DataReader reader=cmd.ExecuteReader();
 }
SqlServer

[SqlProcedure("TestProcedure")]
    public static void StoredProcedure1 ()
    {
        SqlCommand cmd = SqlContext.GetCommand ();
        cmd.CommandType = CommandType.Text;
        cmd.CommandText = "select * from customer";
       
        SqlDataReader reader=cmd.ExecuteReader();
        SqlPipe pipe = SqlContext.GetPipe ();
        cmd.Dispose ();
        pipe.Send (reader);

    }

通过attribute(sql server)和通过wizard(db2)进行deply各有所长，个人无法评判，感觉sql server采用attribute的方法更简捷

对设计的思考
yukon引入.net clr，可能使许多人会有把商业逻辑引入存储过程、触发器等sql元素的冲动，对于我而言，早先e2 erp核心都是基于sql server触发器和存储过程构造，前台使用pb，我直觉的感觉yukon会是升级这个系统的最好选择。但是，请大家注意

1、.net创建的这些sql元素，采用的是static(shared)方法，还是类似于过程式编码。如何将一些设计模式和面向对象的好处引入到这些项目，是我们主要要考虑的问题
2、在beta版本中，SqlContext.GetTransaction还是未支持状态，虽然可以使用

SqlTransaction trans=SqlContext.GetConnection().BeginTransaction() ;

获得一个新事务
3、如果将大量的商业逻辑引入其中，对数据库性能可能会有一定的冲击。而不是大家所想像的更好（可以预见的是，长时间的占用一个连接，锁定等）

所以，推荐大家按项目的实际情况而定，即，如果你有大量的代码在存储过程，触发器，移动到.net过程会使之更容易维护和升级，而如果仅仅是薄薄的一层（现在一般的模式都会使用存储过程包装数据操作，如有个category表，则对应的有addcategory,deletecategory,updatecategory等存储过程），则不必要进行这种迁移。而不是盲目迁移