错误的数据库连接导致dataset设计器无法打开
[ 2006-09-30 15:51:25 | 作者: progame ]
报错信息：
虽然dataset中使用的connectstring为property.setting时的设置是正确的
但仍然无法打开Dataset designer.
最后删除Server Explorer中的数据库连接解决
load dataset error
该项不适于在指定状态下使用
not valid for use in specified state
该项不适于在指定状态下使用
not valid for use in specified state
虽然dataset中使用的connectstring为property.setting时的设置是正确的
但仍然无法打开Dataset designer.
最后删除Server Explorer中的数据库连接解决
sql server 2000的一个bug
[ 2006-09-23 12:24:43 | 作者: progame ]
select month(OrderDate) as CurrentMonth,sum(dbo.GetJobOrders(OperationID)) as HBLs, count(*) as Jobs,
sum(case when LoadingType = 'FCL' then dbo.GetContainersBySize(OperationID,'20') else 0 end + 0 -0) as FCLCTN20,
sum(case when LoadingType = 'FCL' then dbo.GetContainersBySize(OperationID,'40') else 0 end + 1 -1) as FCLCTN40,
sum(case when LoadingType = 'FCL' then dbo.GetContainersBySize(OperationID,'HQ') else 0 end + 2 -2) as FCLCTNHQ,
sum(case when LoadingType = 'FCL' then dbo.GetContainersBySize(OperationID,'45') else 0 end + 3 -3) as FCLCTN45,
sum(case when LoadingType = 'CONSOL' then dbo.GetContainersBySize(OperationID,'20') else 0 end + 4 -4) as LCLCTN20,
sum(case when LoadingType = 'CONSOL' then dbo.GetContainersBySize(OperationID,'40') else 0 end + 5 -5) as LCLCTN40,
sum(case when LoadingType = 'CONSOL' then dbo.GetContainersBySize(OperationID,'HQ') else 0 end + 6 -6) as LCLCTNHQ,
sum(case when LoadingType = 'CONSOL' then dbo.GetContainersBySize(OperationID,'45')
...sum(case when LoadingType = 'FCL' then dbo.GetContainersBySize(OperationID,'20') else 0 end + 0 -0) as FCLCTN20,
sum(case when LoadingType = 'FCL' then dbo.GetContainersBySize(OperationID,'40') else 0 end + 1 -1) as FCLCTN40,
sum(case when LoadingType = 'FCL' then dbo.GetContainersBySize(OperationID,'HQ') else 0 end + 2 -2) as FCLCTNHQ,
sum(case when LoadingType = 'FCL' then dbo.GetContainersBySize(OperationID,'45') else 0 end + 3 -3) as FCLCTN45,
sum(case when LoadingType = 'CONSOL' then dbo.GetContainersBySize(OperationID,'20') else 0 end + 4 -4) as LCLCTN20,
sum(case when LoadingType = 'CONSOL' then dbo.GetContainersBySize(OperationID,'40') else 0 end + 5 -5) as LCLCTN40,
sum(case when LoadingType = 'CONSOL' then dbo.GetContainersBySize(OperationID,'HQ') else 0 end + 6 -6) as LCLCTNHQ,
sum(case when LoadingType = 'CONSOL' then dbo.GetContainersBySize(OperationID,'45')
阅读全文...
八月桂花香 NUnit来帮忙
[ 2006-09-20 21:43:55 | 作者: progame ]
一路上到处的桂花香，时间在不知不觉中流逝，而代码，也在不知不觉中膨胀，并且越来越有“坏味道”...
现在IDE的debug功能越来越强悍，当一切回归原始，当你只能自己输出调试信息，只能看到出问题的代码位置和函数名时
你才知道，你的设计是多么地差，有太多不相关的功能耦合在一起，以及一次次的不知所终的调用，还有颗粒性不够细的单元测试
如果你很难根据出错信息迅速地定位你的问题所在，那么这个时候，放心地去怀疑你的设计吧
去用无法直接调试的单元测试检测你代码是否简洁吧，一如我这篇简洁的日志
现在IDE的debug功能越来越强悍，当一切回归原始，当你只能自己输出调试信息，只能看到出问题的代码位置和函数名时
你才知道，你的设计是多么地差，有太多不相关的功能耦合在一起，以及一次次的不知所终的调用，还有颗粒性不够细的单元测试
如果你很难根据出错信息迅速地定位你的问题所在，那么这个时候，放心地去怀疑你的设计吧
去用无法直接调试的单元测试检测你代码是否简洁吧，一如我这篇简洁的日志
感受ADO.Net 2.0
[ 2006-09-08 21:55:40 | 作者: progame ]
一个很小的 WINFORM 程序，涉及到 CRUD，一次写入(批量更新)，存储过程交互，数据比较，数据缓存，麻雀虽小，倒也五脏俱全，于是懒得去找那些.Net下的ORM了，省得去代码生成，属性配置，既然ADO.Net2.0已经提供了 QueryBuilder，Typed DataSet，DataBinding，那就直接上吧!
拖，拉，配，拖，拉，配.......
开始很机械的操作，一番云里来雨里去之后，功能是完成了，但就我所体会到的 ADO.Net 2.0 有以下感觉：
优点：
1、性能
据说性能比1.0有巨大提升, 反正我感觉还是挺快的，即使在配置较差的电脑上，另外，使用Sql Profier监测自己软件的SQL还是很重要的， 这样你能更清楚的知道 DataSet 何时提交，提交了什么样的 SQL
2、内存数据操作
这个真是非常好的一个特性，配合 GRID ，可以很好地实现一次写入，也就是可以 Undo 了，不怕误操作再来数据的错误，而且后期的设定 PK ，再用 FIND 方法定位，给两个数据集之间进行比对提供了极大的便利。 此处，可以凭空创建一个 DataTable， 任意改变其中的 Columns, Constrains， 这对于数据处理而言， 意思非常巨大， Table 的行集操作能力结合.Net语言的其它超强处理能力，真的有一种农奴翻身做主人的感觉，因为现在数据完全是可控的了
3、Query Builder
一些既不算简单又不复杂的 SQL 可以写在这里，省却了代码中直接写入的换行+ @ 标识，又没必要搞得 DB 中 SP 漫天飞舞(貌似MS本身特别钟爱在 SQL SERVER 中用超多的 SP，好像在向大家说：量再多也不怕!)，不管如何，我觉得这是很好地把 SQL 和 CODE 分离的一个举措，所以除了 DataSet 中，其它地方我都不会出现 SQL，如果需要写SQL，那么找相关的 DataSet 去 Add Query 就是了
4、版本控制
因为更新时它使用的是set ... = newValue where field = oldValue的方法 所以如果其它人在你修改时改动了数据， 它会报冲突错误的， 当然，好的方法还是自己通过timestamp来控制
5、Typed
总算可以打点了，将就一点吧，能用就行了
缺点：
1、命名空间混乱
...
阅读全文...
拖，拉，配，拖，拉，配.......
开始很机械的操作，一番云里来雨里去之后，功能是完成了，但就我所体会到的 ADO.Net 2.0 有以下感觉：
优点：
1、性能
据说性能比1.0有巨大提升, 反正我感觉还是挺快的，即使在配置较差的电脑上，另外，使用Sql Profier监测自己软件的SQL还是很重要的， 这样你能更清楚的知道 DataSet 何时提交，提交了什么样的 SQL
2、内存数据操作
这个真是非常好的一个特性，配合 GRID ，可以很好地实现一次写入，也就是可以 Undo 了，不怕误操作再来数据的错误，而且后期的设定 PK ，再用 FIND 方法定位，给两个数据集之间进行比对提供了极大的便利。 此处，可以凭空创建一个 DataTable， 任意改变其中的 Columns, Constrains， 这对于数据处理而言， 意思非常巨大， Table 的行集操作能力结合.Net语言的其它超强处理能力，真的有一种农奴翻身做主人的感觉，因为现在数据完全是可控的了
3、Query Builder
一些既不算简单又不复杂的 SQL 可以写在这里，省却了代码中直接写入的换行+ @ 标识，又没必要搞得 DB 中 SP 漫天飞舞(貌似MS本身特别钟爱在 SQL SERVER 中用超多的 SP，好像在向大家说：量再多也不怕!)，不管如何，我觉得这是很好地把 SQL 和 CODE 分离的一个举措，所以除了 DataSet 中，其它地方我都不会出现 SQL，如果需要写SQL，那么找相关的 DataSet 去 Add Query 就是了
4、版本控制
因为更新时它使用的是set ... = newValue where field = oldValue的方法 所以如果其它人在你修改时改动了数据， 它会报冲突错误的， 当然，好的方法还是自己通过timestamp来控制
5、Typed
总算可以打点了，将就一点吧，能用就行了
缺点：
1、命名空间混乱
...
阅读全文...
1
