我想创建一个如下所示的proc,但它在语法上有错误.谁有人指出这个问题？
Create PROCEDURE [dbo].[my_proc] AS
BEGIN
DISABLE TRIGGER dbo.tr_name ON dbo.table_name
-- some update statement
ENABLE TRIGGER dbo.tr_name ON dbo.table_name
END
** Error Message : Incorrect syntax near 'ENABLE'.
有没有人在开发控件时找到了解决DesignMode问题的有用方法？
问题是,如果嵌套控件,则DesignMode仅适用于第一级.第二级和更低级别的DesignMode将始终返回FALSE.
标准的hack一直在查看正在运行的进程的名称,如果它是"DevEnv.EXE"那么它必须是studio,因此DesignMode真的是真的.
问题是寻找ProcessName通过注册表和其他奇怪的部分工作,最终结果是用户可能没有查看进程名称所需的权限.另外这条奇怪的路线很慢.所以我们不得不堆积额外的黑客来使用单例,如果在请求进程名称时抛出错误,则假设DesignMode为FALSE.
确定DesignMode的一个很好的干净方法是有序的.让微软在框架内部修复它会更好!
使用典型系统之一,ODBC,OLEDB或ADO.NET与SQL Server数据库进行通信时,底层基本协议是否相同？这些系统之间的所有差异基本上只是客户端问题吗？
这些只是TDS(表格数据流)传输的不同风格吗？
或者有实际的不同方式与数据库服务器通信,这些协议之间有根本区别吗？
考虑我正在与将以某种格式发送消息(数据库表,消息队列,Web服务)的外部系统连接.在"消息头"中有"MessageType",它是1到20之间的数字.MessageType定义了如何处理消息的其余部分.有新的,修改的,删除的,取消的......
我的第一个倾向是设置枚举并定义所有类型.然后将数字解析为枚举类型.将它作为枚举,我将设置典型的开关案例系统,并为每种消息类型调用特定方法.
一个大问题是维护.
开关/箱体系统笨重而且很笨重,但它非常简单.
各种各样的表/配置系统可能很难让其他人知道并添加新消息或调整现有消息.
对于大约12个MessageTypes,交换机/案例系统似乎非常合理.切换到表驱动系统的合理截止点是什么？
哪种系统最适合处理这些类型的问题？
我在这里为C#和Java设置了一个标签,因为它绝对是一个常见的问题.还有许多其他语言具有相同的问题.