谢谢你,朋友,这个问题困扰我很长时间了
page_load事件为什么要触发两次呢

一路看下来，收获不少。。。
关于 sql语句和存储过程各自的优点，缺点大家是描述的淋漓尽致了

我认为这两点没有必要非得比个你死我活，谁好用就用谁。我想说一点上面没有讨论到的地方：使用二者之间的网络流量。
我不知道为什么大家都把这点忽略了，如果网络是按照流量来计费的（国外好多都是按照流量），二者的差距还是有的。。。

很有用..谢谢

这个我也遇到了
不过我比你好，我的是空间商那里把.NET的版本设置错了，结果很多TEXTBOX都不能用了，改了几页代码。后来检查一下，发现出错提示的版本是2.0的，呵呵

谢谢!!!!!!!!!!!

什么乱七八糟的,你自己去试试能不能执行!别在这里乱七八糟!!!

谢谢。

哎，om****讲话注意一点啊，人家没什么了不起，你就了不起吗？而且我发现现在大多数人只是说自己的程序大而已，有几个动不动就是几百W的数据，又有几个一天的数据增量就上G的，我接触的一些企业的应用是挺大，也不可能有这么大吧。动网论坛够大的了吧，他们有一天上G的增量？难道你们做的B/S都是TOM、163？那直接静态htm就得了。

发送方怎样得到公钥?你这是在一个程序里,在网上是两台计算机啊?用下载CA证书行吗?用插件行吗?

一句话，别拿ERP的应用来说性能的事

你做ERP了不起吗,就你那点人访问算什么,4-5W人的话，同时访问的概率有多少,根本不是什么高流量的应用.

真搞不懂为什么03，05都支持这个功能，而且用的很爽的
到08里面要把它去掉，太气人了

用CSS吧
直接
input
{
font-family:xxx;
}

@Dream world 梦想天空
改源代码也麻烦啊, 不知道这帮人在想什么. 而且他还说了, 即使将来出sp1, 也不会把这个包含进来, 要下一代的vs 才会支持. 晕死.

啊？这样的话~~~~~~~~~~~~~看来只有直接改源代码了。有些时候也不要太依赖于IDE了~

我在vs2008中一点设计视图就停止响应，直到我结束任务。不知道什么原因，好象我刚刚安装的时候可以。过了几天就不行了。

楼主的观点有问题，left都不用，难道100w条数据你也拿到内存中来做处理？！要知道普通x86程序只有3GB内存可以使用，如果数据量一大，必定Out Of Memory，但是数据库的left是做过优化的，怎么会一样~~照你这么说也不要DBMS了，都用文件存数据，用程序自己来拼接数据好了~~

@老Q
呵呵, 的确是有这个问题, 不过根据引用的局部性, 一般情况下, 一段时间内应该都会在同一个子文件夹下工作, 跨越两个以上文件夹的机会不应该太多, 所以还可以接受了

昏倒，最烦这个功能了，修改文件一多，就把我的解决方案树都展开了
我还要一个一个的关起来，我找了好久才知道怎么关了这个功能

good:)

我也喜欢用readonly
唉，估计也要惨了，我现在还在用vs2003
还是等vs2008 sp1出来后再转吧

有意思，但还没有碰到过

@GoGoSonny
已经确认, 果然装了sp1 就好了, 多谢多谢!!

@坚强2002
@longer
不好意思,是我贴示例图片的时候一时大意, 忘写contentTemplate了.

这个我当然是知道的, 而且我也提到了, 我的程序最终是可以正常运行的, 不管是scriptManager 还是Proxy , 或是updatePanel, 智能感知根本不工作, 手写出来提示错误, 在正常的页面上, 即使缺少scriptManager, 写updatePanel 的时候也是有智能感知的, 而且编译也没有问题, 只有在运行的时候才会因为缺少scriptManager 而报错.

@GoGoSonny
谢谢, 可能是这个原因, 这两天太忙, 还没来得及验证, 准备今天装一下试试看.

<asp:Content ID="Content1" ContentPlaceHolderID="ContentPlaceHolder1" Runat="Server">
<asp:ScriptManagerProxy id="ScriptManagerProxy1" runat="server">
</asp:ScriptManagerProxy>
<asp:UpdatePanel id="UpdatePanel1" runat="server">

<contenttemplate>
<asp:Button id="Button1" runat="server" Text="Button" OnClick="Button1_Click"></asp:Button> <asp:Label id="Label1" runat="server" __designer:wfdid="w6" Text="Label"></asp:Label>
</contenttemplate>
</asp:UpdatePanel>

</asp:Content>

你说的这个方法有点局限啊，如果GridView里的数据是数据库里的数据就不用写后台代码了，直接用绑定语句就可以了，该怎么添加呢？

其实很简单 放在updatepanle里面的内容是要放在ContentTemplate里面的 例如
<asp:UpdatePanel ID="UpdatePanel1" runat="server" RenderMode="Block">

<ContentTemplate>

这里面放按钮之类的内容

</ContentTemplate>

</asp:UpdatePanel>

VS2005 SP1

刚才试过了, 还是不行啊, 你们都没有碰到这样的情况吗?

你没加<asp:ScriptManager id="ScriptManager1" runat="server" EnablePageMethods="True" EnableScriptGlobalization="True" EnableScriptLocalization="True">
</asp:ScriptManager>。并且在母版页头上添加<%@ Assembly Name="System.Web.Extensions" %>这句

MS也太搞了。

说些个人看法，我感觉在代码里拼接大量sql语句，看起来很乱，而且以后修改也不方便，还要重新编译，我觉得一些业务逻辑能在sql里处理的，就在sql里做。处理同样的逻辑，在代码里处理和在存储过程里处理的速度差些，毕竟你在代码里处理要涉及到语句的传递，再说用什么应该统一起来吧，别这里写两个语句，下面就用存储过程，那样也太乱了看起来。

另外再支持一下楼主观点，使用SQL优先于SP，数据库不应该包含太多商业逻辑，这不符合三层架构的设计理念（浏览器，应用服务器，数据库），从长期看数据库包含太多的商务逻辑也会拖累数据库的性能

你要检查一下执行计划，比较一下，应该两个方法是不一样的，如果SQL Server在绑定变量的时候就是不愿意用索引的话，可以在SELECT后面加/*+ INDEX(index_name) */这样的hint强制使用索引（起码Oracle下面是这样的，SQL Server应该也类似）

我在用day1和day2变量的时候传入的本来就是DateTime类型，不是string类型。

那样的话，SQL语句改动一下也许能够用上索引，将day1和day2绑定为Date类型试试（SQL应该有类似于to_date()的函数的）。可能你写文本量'2007-10-10'，SQL Server恰好能智能地转换为DATE类型，就走索引了，但是变成变量就走string比较了，SQL Server我不熟，我只是猜猜而已，见笑了

我用的是SQL Server，语句是Select Count(*) from table where addtime>=@day1 and addtime<@day2，day1和day2相差一个月（有时候一天也会出错）。但是直接拼成Select Count(*) from table where addtime>='2007-10-10' and addtime<'2007-11-10'就没问题。我觉得这两种情况应该都会用索引的吧？

很可能是因为你取count(*)的时候，直接写时间，Oracle数据库(如果是Oracle的话)CBO优化器可以根据统计信息，得到你查询时间区段占总数据的比例很小，就走索引了，因此快，但是使用绑定变量后，oracle就不知道这个信息，就傻傻的走全表扫描了。

我知道移动公司做数据处理生成报表的时候，是把所有用到的数据复制到另一套数据库里去做的。

我遇到过一个问题，在一个相当大的表里面（数据多，字段很少）根据时间字段取count(*)，我是在程序里直接传SQL的，如果把时间值直接拼入字符串，执行是没有问题的，但是如果使用SQLParamter，再把时间作为参数传递给SQLCommand，执行就会超时。

讨论这么激烈.
基本同意博主的意见. 但是有些情况下,为了减少链接只能写一些存储过程,无可避免.

@木刀
我的观点是数据库其实还是很经得起折腾得
他有很多潜力没有被人挖掘出来

你的做法也一样会让应用服务器负荷日益增加

我可能理解你这么做的原因，因为我们都是程序员
能用程序来解决问题是我们最自然的想法

并且正如你说的，很多时候将压力转到应用服务器其实是会节约时间的。

因此，有你这样的结论就很自然的。

但是就如同谈论什么时候才需要OO一样。一个这里好的做法，不一定永远是好的
程序的分层，就是要让程序每层各司其职。互相降低耦合。

针对实际项目，只要合适的方法就是好的。

但是我们如果是讨论类似于应用JEE规模的项目。讨论理想和尽量通行的做法。
让应用层分担数据库的固有功能，那才算是小技巧呢。

在大型项目的持续维护中，数据库的表结构不会永远不变的。
数据库不会永远仅仅是一个数据库服务器的。
并且，这一切都可能在项目运行过程中发生变化并进行解决的。
这时候才是内嵌SQL的死穴。

你的做法，能够救项目于一时。不能救项目于一世

自然，我知道我国的99%的项目都是做的一锤子买卖
收钱，走人。
只要完成功能，今后的维护？谁管？
数据表太大了，要进行垂直拆分？内嵌SQL还能用吗？

我对Oracle数据库较熟悉，我倾向于优先使用SQL，理由是SQL有数据库并行执行和Materialized View物化视图重写功能，分析SQL的执行计划也比较方便。

@徐少侠
"这两种方式其实仅仅是将压力从数据库服务器转移到了应用服务器。整体的系统压力还是在的。" 呵呵, 这个是当然的, 我在这一问题上的观念是: 假设一个需求用数据库服务器来承担是10, 在应用服务器上是20, 也要移到应用服务器上去, 更何况, 实际上我认为在应用服务器上很可能会是5甚至更少.

我之所以说不满主要是你用太多篇幅来证明存储过程好, 似乎你没有认真看我的原贴, 呵呵, 我在原贴中花了不少笔墨来弄清我的立场, 我不想在这里讨论存储过程是不是好于sql语句, 因为我的前一篇已经大量的讨论过了, 并且有人批评说这种争论是"月经博", 每过几个月就会说一次, 让我很汗颜, -----不仅是我, 我想任何人也不会认为存储过程的效率低, 我个人的态度仍然是尽量地不用存储过程, 不过我并不想再继续讨论这一点, 我之所以不愿意用存储过程, 当然是因为其它原因, 而不是存储过程的效率低下.

关于数据库的使用程度, 这才是我关心的point, 如你所说, 我认为数据库只应承担存取数据的工作, 甚至可以说, 使用复杂的sql 语法, 或是数据库附带的其它非数据操作功能, 我觉得这些是"奇技淫巧", 不值得提倡使用. 原因很简单, 出发点仍然是尽一切可能为数据库减轻工作压力.

前面我也说过, 一个工作即使数据库更擅长, 只要有可能转嫁给应用服务器, 就毫不犹豫地转嫁给它, 即使这个工作要增加一倍的代价也在所不惜. 只让数据库做它最基本, 最擅长的工作, 它肯定会做得更快更好.

--引用--------------------------------------------------
木刀: @徐少侠
在这里我只是想旗帜鲜明地反对很长的, 包含了业务逻辑的存储过程.
--------------------------------------------------------
这样哦

所以我觉得还是例子不好。

另外，报表服务就是数据库本身应该做的一件事情，绝不是什么其他的
SQL2005甚至已经将Report Service集成到了里面
联机数据分析服务也是已经历史悠久的商业决策依据

你的例子里面使用生成报表时候的计算过程会大大影响应用系统性能的问题，其实就是分析服务所应该完成的功能。

因此。我的后半段文章就是给你指出解决的方式。

@木刀
在你的文章中，体现的思想是仅仅将数据库做为简单的数据存储的位置。
数据库除了保存或返回数据，没有过多的功能了
你建议将业务逻辑尽量都放在代码中，这个自然不算大的分歧

我提了些批评
主要出于这写考虑
首先不要仅仅因为一点点的问题就否定存储过程的意义
第二，你拿来进行论证的例子其实即使使用再好的程序代码，如果没有正确地使用数据库技术进行解决，你也是解决不掉的。假设我们大家的项目的数据库都只有一个数据文件的话，那任何提升性能的方法即使能提升，也绝对是缘木求鱼。如果因此再去使用各种其他技术？好啊，有什么意思呢？

解决项目的性能问题，要看准问题的所在。

如果抛开任何环境，我坚持我的一个观点
只要语句一样，存储过程的执行就是要比发送SQL要快
因此，即使你使用若干语句，将人家的几十行的存储过程转变成了一个SQL加上你的程序代码
我只要将你最后那个SQL转变成存储过程。整体执行速度就一定比你的快

这两种方式其实仅仅是将压力从数据库服务器转移到了应用服务器。整体的系统压力还是在的。

因此，这种例子并不是证明存储过程或内嵌SQL哪个更好的准确的例子

--引用--------------------------------------------------
邹健: @徐少侠
学到很多知识....那分表时 我要怎么查询呢?进行连接? 一个服务器上好说,但如果在不同服务器上不同的数据库内呢,有没有相关解决方案的书或可以学习呢,希望推荐....
--------------------------------------------------------
一个设计良好的数据库，通过使用存储过程来暴露功能。在程序代码中根本不会感觉数据库的设计的不同。即使它其实是跨了服务器的。这一切都由数据库自己来管理。
因此，在进行查询时和平时写语句没有什么区别。即使是直接在代码中写语句，也 依然是类似Select * from Table1 where data between '2000-1-1' and '2003-12-31'
数据库的设计是和数据的使用必然关联的，有什么样的使用，并且因此造成性能损失，那么就需要DBA进行数据库性能分析并加以解决。
这个时候，如果是代码内嵌SQL。那么数据库的任何一个变更都足以使得软件修改至少若干天。还要回归测试若干天。
中国的程序员在讨论问题的时候老爱拿身边的例子。这个本来不错。
错就错在我们身边的例子都如同玩具一样。
没有多少人真正考虑大型项目的需求。没有多少人能理解Win操作系统是怎么弄出来的。

要学的话至少可以先看看SQL自带的联机帮助
能搞懂联机帮助50%，做一个DBA是没问题的了

2日不见，居然又有了这么热烈的讨论，真实太高兴了。
首先，讨论存储过程还是嵌入Sql，需要分清楚场合。要看你的数据库是集中式的还是分布式的。根据网络拓扑来判断可能的瓶颈所在。
抛开是不是应该把包含业务逻辑的存储过程放在数据库的问题。
我们光从性能上来说，存储过程的问题在于大量占用了数据库服务器的计算资源。举个例子，某电信的网络计费系统在结账的时候，用了一台小型机，上面装了Oracle数据库，用了一个超大的存储过程来进行结账的操作，执行一次要跑好几个小时。博主也是在高并发大数据量的系统的环境下才会感觉到执行存储过程对数据库服务器所带来的负担。不过对于这类系统，我觉得无论是存储过程还是嵌入Sql都会有制约的瓶颈。其实用一台Oracle的TimeTen作为前端数据缓存对性能的提高才会有比较显著的改善。

@徐少侠
说句实在话，对你的评论很不满......你花了一半篇幅证明存储过程的效率高于sql语句, 难道我有在任何时候说过, 存储过程的效率低了么?

你的后一半篇幅跟我所讲的主题也没有任何关系, 不知道你为什么会以此为论据来批评我, -----我不是听不得批评, 只不过被批得有点莫名其妙, 呵呵.

"数据库是一门博大的技术", 这是当然, 由于涉及的东西太多, 所以不可能把"数据库" 当做话题来讨论, 否则会死人的. 在这里我只是想旗帜鲜明地反对很长的, 包含了业务逻辑的存储过程.

存储过程的临时表。游标等可以用DataSet,数组，循环等代替.