偶尔#Type！错误 [英] occasional #Type! error

问题描述

访问2010.accdb只是fyi    分开前/后 大约6个全职用户....

Access 2010.accdb just fyi     split front/back  about 6 full time users....

该应用程序偶尔会定期但会引发#Type！将错误转换为表单文本框。 故障排除似乎表明延迟是由于前/后在同一台PC上或仅在1段的另一个网络上测试（前/后
PC连接到同一路由器）时不会发生延迟。 不涉及无线。

The app occasionally but regularly throws #Type! errors into form text boxes.  Trouble shooting seems to indicate latency caused in that it does not occur ever when front/back are on same PC or tested on another network of just 1 segment (front/back PC connected to same router).  No wireless is involved.

主要的屏幕形式很复杂，但我认为设计正确。 它有一个连续的子表单，总结了几列。 子表单总和在主表单中用于数学 - 并且用户需要查看其他表中的值，因此
是带有DlookUps的文本框，来源于相当复杂的查询 - 这也涉及到数学在主窗体中。

The main screen form is complex, but I believe correctly designed.  It has a continuous sub form with a few columns summed.  The sub form sum is used in math in the main form - and the users have a need to see values from other tables so there are textboxes with DlookUps sourced on fairly complex queries - which also are involved in math in the main form.

此主屏幕有一个用于打开报表对象的按钮。 此报告是主要用于打印的摘要，其中包含从主屏幕汇总数学字段的字段。

This main screen has a button to open a report object.  This report, which is a summary primarily used for printing, has fields that sum math fields from the main screen.

即。 = Forms！MainScreen.Text1 + Forms！MainScreen.Text2

i.e. =Forms!MainScreen.Text1 + Forms!MainScreen.Text2

#Type！错误，这是间歇性的，通常在报告中看到。 但它有时会以某种形式发生。 如上所述 - 如果网络被取出，它永远不会发生。 用户可以经常关闭/重新打开然后它可以工作
ok。 没有看到腐败的迹象 - 再次一切正常，取决于所解释的部署。

The #Type! error, which is intermittent is typically seen in the report.  But it does happen in the form sometimes.  As noted above - if the network is taken out of the picture it never happens.  Users can often close/reopen and then it works ok.  Not seeing signs of corruption - again everything works fine depending on the deployment as explained.

我已经考虑通过为它创建一个相当复杂的查询记录源来消除报告中的任何计算字段 - - 但在走下去之前会欢迎一些经验丰富的建议 - 因为延迟问题可能会影响它。

I have considered eliminating any calculated fields in the report, by creating a fairly complex query record source for it - - but before going down that road would welcome some experienced advice - as the latency issue may affect it regardless.

IT人员正在调用它以了解他们可以对延迟做些什么改进这是箭头指向的情况。我现在的理论是，由于延迟变化（随机网络速度变化） - 有时报告
或表单对象正在打开而没有所有数据可用，这就是错误被抛出的原因。 考虑到这一点的部分原因是用户已经要求对每个版本进行越来越多的计算 - 现在问题就出现了
，我想知道是否有一个'稻草打破骆驼的后退'问题延长处理的条款导致延误......这是否合情合理？

The IT folks are being called it to see what improvements they can do to the latency situation as that is where the arrow points at the moment. My theory at the moment is that due to changing latency (random network speed changes) - sometimes the report or form object is opening without all the data being available and that is why the error gets thrown.  Part of the reason for thinking this is that the user has asked for more and more calculations with each version - and the issue just is now surfacing and I wonder if there is a 'straw breaking the camel's back' issue in terms of extended processing caused delays...... Is this plausible?

推荐答案

空字段会导致计算出现问题。试试这个：

Null fields will cause problems with calculations. Try this:

= Nz（Forms！MainScreen.Text1,0）+ Nz（Forms！MainScreen.Text2,0）

< span style ="color：＃2a2a2a; font-family：'Segoe UI'，'Lucida Grande'，Verdana，Arial，Helvetica，sans-serif; font-size：14px; line-height：21.5319995880127px"> Nz（）如果Text1或Text2为空，则替换为零。

这篇关于偶尔#Type！错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！