零星的ASP.NET数据错误：＆QUOT;无法找到表0 QUOT; [英] sporadic ASP.NET data error: "Cannot find table 0"

问题描述

已经部署了一个ASP.NET网站的一个新的版本在生产环境中，我记录数十个数据错误的每一秒，几乎总是出现错误无法找到表0。我们使用的数据集，并经常提到表[0] ，虽然我理解访问表[0前检查表的数据集的防御性编码实践] ，它从来没有在过去的一个问题。特定的页面将加载精细一秒，然后会丢失其数据驱动的组件下一之一。只是看到，如果这听起来很耳熟的人。

Having deployed a new build of an ASP.NET site in a production environment, I am logging dozens of data errors every second, almost always with the error "Cannot find table 0." We use datasets and frequently refer to Table[0], and while I understand the defensive coding practice of checking the dataset for tables before accessing Table[0], it's never been a problem in the past. A certain page will load fine one second, and then be missing one of its data-driven components the next. Just seeing if this rings a bell for anyone.

更多的细节：我用的不同版本这个时候服务器，而我想象中的编译器设置上都是相同的，我有一个硬时间思考，有一个开关，使50％我的数据库调用回来，没有表。我的切换项目2008 VS ，但随后恢复所有的这些改变，当我换回到2005年VS我注意到，在内置组件有一个新的在MyLibrary .XmlSerializers.dll ，它没用过，但我也无法想象，这是造成所有的麻烦。 （它也不会比其他任何时候倒在调用的在MyLibrary 的，或者至少是没有更多的。）

More detail: I used a different build server this time, and while I imagine the compiler settings are the same on both, I have a hard time thinking that there's a switch that makes 50% of my database calls come back with no tables. I also switched the project to VS 2008, but then reverted all of those changes when I switched back to VS 2005. I notice that the built assembly has a new MyLibrary.XmlSerializers.dll, where it didn't used to, but I also can't imagine that that's causing all the trouble. (It also doesn't fall down on calls to MyLibrary, or at least no more than any other time.)

更新补充：？我发现麻烦的构建是一个释放建设，这里的工作版本编译的调试莫非解释

回滚到构建这些变化固定它。 （重新启动SQL Server时，我们之前试过的一步，也没有）。

Rolling back to the build before these changes fixed it. (Rebooting the SQL Server, the step we tried before that, did not.)

麻烦也似乎是基于负载的 - 通过我们的整合和QA环境中，此节战罢没有问题，甚至我们的烟雾测试环境 - 指向生产数据之一 - 在轻负载细

The trouble also seems to be load-based - this cruised through our integration and QA environments without a problem, and even our smoke test environment - the one that points to production data - is fine under light load.

这是否有任何东西的显着特点，你可能会在过去所看到的？

Does this have the distinguishing characteristics of anything you might have seen in the past?

推荐答案

我见过类似的东西。我相信，我们的问题曾与失败的会话做被重新使用（一次会话对象失败它进入状态不佳而无法恢复。）我们通过增加存储器的会话池并增加纸幅的频率固定它应用回收再利用。

I've seen something similar. I believe our problem had to do with failed sessions being re-used (once the session object failed it went into a poor state and could not recover.) We fixed it by increasing the memory for the session pool and increasing the frequency of the web application recycling.

这也被一个新的版本，乍一看似乎没有任何改变，以产生这种效应造成的。但是，它最终变得清晰，程序逻辑被打开和关闭更多的连接（也许20％），比以前多了。这个小变化推动我们事先配置的限制。

It also was "caused" by a new version that at first blush did not seem to have any change to cause such an effect. However, eventually it became clear that the logic of the program was opening and closing a lot more connections (maybe 20% more) than it used to. This small change pushed the limit of our prior configuration.

这篇关于零星的ASP.NET数据错误：＆QUOT;无法找到表0 QUOT;的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！