现在公司有个项目(外包给别人做的)老是在操作过程中报“数据库连接池已达最大连接数”的错。我检查了下程序,里面都是用的DataReader,里面的数据库连接也关了的。但是就是一个用户操作次数多了,就报错,运行不了。他的数据库连接串写在global的Application_Start事件里的Sub Application_Start(ByVal sender As Object, ByVal e As EventArgs)
' Code that runs on application startup
Application("MyITSchoolConnectionString") = "server=.\SQLEXPRESS;uid=abc;pwd=1234;database=test"
End Sub会不会是因为这个的关系啊
' Code that runs on application startup
Application("MyITSchoolConnectionString") = "server=.\SQLEXPRESS;uid=abc;pwd=1234;database=test"
End Sub会不会是因为这个的关系啊
解决方案 »
- 未将对象引用设置到对象的实例
- xml.net
- 服务区端怎么调用客户端的JS
- int PID = Convert.ToInt32(MyGridView1.SelectedRow.Cells[0].Text)怎么得不到值
- SQL取一个月小时段,怎么写
- 安装Visual Studio.NE出现内部错误25003 如何解决?
- 关于asp.net的B/S结构下的单一用户重复登录的方法,请大家帮帮忙,有什么好办法?
- 把集合的值赋值给datatable
- 求助:我用的SelectedIndexChanged不起作用了?
- 一个初学者的问题!请指教!
- aspx页面不能回发 xmlhttp
- 至少一个参数没有被指定值
在finally释放资源会好点。
建议连接字符串放在 web.config 里
这样写并没有任何问题。我建议你首相让这个人负责解决,因为这类问题是低级、隐藏、习惯性问题,如果属于固有编程设计习惯比较不可靠问题不能解决,应该考虑换人或者换系统、换思路。如果你必须自己修改程序,那么你可以把所有的“open数据库连接”的地方都修改为using(...){}形式,在“....”中实例化连接对象。一个地方打开连接,然后别的看似无关的地方(有可能执行也有可能不执行,例如抛出异常时)负责关闭连接,这种面条式的逻辑散布在整个应用程序的不同地方,这是很危险的结构。由于SQL Server连接时基于连接池的,因此你应该在代码结构上就使用using(){}这种结构确保肯定可以及时关闭连接。我不相信人的眼睛可以看出连接是否关闭了,你应该使用程序结构来保证,不要轻易断言“里面的数据库连接也关了”。使用using(){}来管理数据库连接的程序,根本不用去动脑筋冥思苦想是否关闭了数据库,结构上确保必然关闭连接,想不关闭也难。
这个现象完全做出“人工读代码来判断程序运行时BUG不可靠”的结论。推行好的结构,让傻瓜也能写好程序,避免那些貌似很技术化但是忘记了质量控制的编程风格。对程序来说,少写代码,就是最好的编码。