单元递归地使用自身（但事实并非如此）
我有一个数据模块，在我们的一个业务应用程序中使用。它存在于项目中几乎每个单元的实现使用子句中。
我可以修改数据模块的实现部分中的业务逻辑和其他代码，并且可以毫无问题地进行编译。但是，对数据模块的接口部分进行任何更改然后进行编译都会导致编译器错误“Unit MyDataModule recursively use myself”。构建而不是编译可以使错误消失。
这是我以前从未见过的新作品。当然，我已经检查过以确保数据模块无法被递归使用，如果确实如此，构建不会改变任何东西。
有谁知道如何追踪或解决这个问题？每次向数据模块引入新的查询或方法时，都必须进行编译、关闭错误对话框，然后进行构建，这真的很烦人。
编辑：解决下面和 @Marjan 的回答中的一些评论：
我没有使用 Variants 或调试 dcus。我在其中一个 Google 搜索结果中尝试了一种解决方案，该解决方案看起来有希望损坏的 .identcache 或 .local 文件，但这并没有成功。
尝试过@Jørn的建议；清理所有临时文件并编译 .dcus，进行编译，一切正常。对接口进行了更改（在数据模块的类声明的私有部分声明了一个布尔变量），然后按 Ctrl+F9 进行编译。错误。进行了构建，一切都很好。然后编译就可以正常工作了。删除布尔值，尝试编译：错误。
我有大约 20 个大小相似的项目 (~750K-1M LOC)，但没有一个表现出这种行为。我已经四次检查数据模块不在项目中任何单元的接口部分中。数据模块本身并不是很大（从'unit'到'end.'总共8,345行，包括注释和空行）。 .dfm（视为文本）共有 8,916 行。
编辑2：我想我必须接受（无论如何现在）这是一个编译器故障。我将尝试重新安排一些内容，将某些功能分解为一个单独的数据模块，看看它是否存在大小限制（可能是 DFM 中的项目）或其他问题。感谢大家的努力。
I have a datamodule that's used thoughout one of our line of business apps. It's in the implementation uses clause of almost every unit in the project.
I can modify business logic and other code in the implementation section of the datamodule and compile without any issues. However, any change to the interface section of the datamodule and then compiling results in the compiler error "Unit MyDataModule recursively uses itself". A build instead of a compile makes the error go away.
This is a new one I haven't seen before. Of course, I've checked to make sure that there's no way the datamodule is recursively used, and if it were in fact, the build wouldn't change anything.
Does anyone have any ideas of how to track this down or fix it? It's really annoying to have to compile, dismiss the error dialog, and then build every time a new query or method is introduced to the datamodule.
EDIT: Addressing some of the comments below and in @Marjan's answer:
I'm not using Variants or debug dcus. I've tried a solution in one of the Google search results that looked promising about corrupt .identcache or .local files, but that didn't pan out.
Tried @Jørn's suggestion; cleaned up all temp and compiled .dcus, did a compile, and all is well. Made a change to the interface (delared a Boolean variable in the private section of the datamodule's class declaration), and hit Ctrl+F9 to compile. Error. Did a Build, all is well. Compile then works fine. Delete the Boolean, try a compile: error.
I've got roughly 20 projects of similar size (~750K-1M LOC), none of which exhibit this behavior. I've quadruple-checked that the datamodule isn't in the interface section of any of the units in the project. The datamodule itself is not extremely large (a total of 8,345 lines from 'unit' to 'end.', including comments and blank lines). The .dfm, seen as text, is a total of 8,916 lines.
EDIT 2: I guess I'll have to accept (for now, anyway) that this is a compiler glitch. I'm going to try some rearranging of things to break out some of the functionality into a separate datamodule to see if it's a size limitation (items in the DFM, maybe) or something. Thanks for all the effort.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
您遇到了编译器故障。请参阅 LKessler 的问题： 为什么在 Delphi 中添加 Action 会导致致命错误< /a> 用于发生这种情况的其他情况。
另一个： http://objectmix.com /delphi/633618-option-use-debug-dcus-causes-compiler-error.html 与使用调试 dcu 相关。
如果你用谷歌搜索它（ http:// /www.google.com/search?q=delphi+%22recursively+uses+itself%22+compiler+error ），它似乎自 D4 以来就一直存在......
我猜这是一个编译器故障不是安慰，但至少你并不孤单......
更新
我已经挖出了另外两个链接，其中包含可能的信息。然而他们都在进行专家交流。我通常不包含专家交流的链接，因为我不同意他们的作案方式（要钱才能接触专家）。在这种特殊情况下，我考虑了“作弊”（订阅，获取答案，将其发布在这里并取消我的订阅）来帮助肯，大卫和任何其他受此问题困扰的人。然而，这感觉不对，而且我不打算在订阅时放弃我的信用卡详细信息，即使我可以在他们开始向我收费之前取消。
由于其他人可能对专家交换持有不同的看法和/或可能热衷于做我不准备做的事情，链接是：http://www.experts-exchange.com/Programming/Languages/Pascal/Delphi/Q_10206864.html 和 http://www.experts-exchange.com/Programming/Languages/Pascal/Delphi /Q_23848477.html
这两个问题都被标记为“已解决”和“提问者已验证”。不管这意味着什么。
You are running into a compiler glitch. See LKesslers question: Why does adding Action cause Fatal Error in Delphi for (an)other situation(s) in which this occurs.
And another: http://objectmix.com/delphi/633618-option-use-debug-dcus-causes-compiler-error.html which is related to using debug dcu's.
And if you google for it ( http://www.google.com/search?q=delphi+%22recursively+uses+itself%22+compiler+error ), it seems to have been around since D4...
I guess it being a compiler glitch is no consolation, but at least you are not alone...
update
I have dug up two other links with possible information on this. However they are both on experts-exchange. I normally do not include links to experts-exchange because I do not agree with their modus operandi (asking money for access to experts). In this particular case I considered "cheating" (subscribe, get the answer, post it here and cancel my subscription) to help Ken, David and anybody else afflicted with this problem. However, it doesn't feel right plus I am not about to part with my credit card details at subscription even if I can cancel before they will start charging me.
As others may hold different views on experts-exchange and/or may be keen enough to do what I am not prepared to do, the links are: http://www.experts-exchange.com/Programming/Languages/Pascal/Delphi/Q_10206864.html and http://www.experts-exchange.com/Programming/Languages/Pascal/Delphi/Q_23848477.html
Both questions have been marked "solved" and "asker verified". Whatever that may mean.
然而，遇到了同样的问题，我的解决方案非常小，并且能够找到根：我试图添加到现有项目的单元与我的项目具有相同的名称。重命名项目，一切就结束了。
Hit the same issue, however, my solution was very small and was able to locate the root: the unit that I was trying to add to my existing project had the same name as my project. Renamed project and that was the end of that.
一直在思考。
Delphi 可以将 DCU 放在与 pas 文件不同的文件夹中。
如果编译期间的搜索顺序不稳定，它将首先找到 DCU 并使用其中的接口部分，然后找到 PAS 文件并使用其中的实现。
如果强制 DCU 与 PAS 文件位于同一目录中，问题会消失吗？
Been thinking about it.
Delphi can put the DCU in a different folder than the pas file.
If the search order during compile is flaky it will find the DCU first and use the interface section from that, then find the PAS file and use the implementation there.
If you force the DCU to be in the same dir as the PAS file, does the problem go away?
正如其他人所说，这是一个编译器故障，但我发现尝试使用您的库路径和搜索路径以及您组中每个项目内的 DCU 输出路径很有帮助。简化搜索和库路径，并使用输出 DCU 路径，确保每个项目将其 DCU 文件放在一个单独的文件夹中，该文件夹不在其他项目的搜索或库路径中。
重叠、复杂的搜索或库路径，尤其是共享的 DCU 往往会带来此类问题。
It is a compiler glitch, as someone else said, but I have found it helpful to try working with your library path and your search path, and your DCU output paths inside each project you have in your group. simplify the search and library paths, and with output DCU paths, make sure for example, that each project puts its DCU files in a separate folder that is NOT in the search or library path of the other projects.
Overlapping, or complex search or library paths, and ESPECIALLY shared DCUs tends to bring on such problems.
您是否尝试过使用“-nocache”命令行参数运行Delphi？它为我解决了很多问题。我在 Embarcadero 论坛上的某个地方找到了这个解决方案。
Have you tried running Delphi with the "-nocache" command line parameter? It solved a lot of problems to me. I found this solution somewhere on the Embarcadero forums.
我们有同样的问题。修改一些不相关的文件后随机发生。
在我们的例子中，问题是：
我们的项目环境是：
We had same issues. It happens randomly after modify some unrelated files.
In our case trouble was:
Our project environment is: