VB6'；内存不足'；可以在一台机器上编译，但不能在另一台机器上编译

这是一个几乎花了一整天时间才解决的问题。我想我会告诉你我的电脑出了什么问题，以及我是如何解决的，以防其他用户仍然使用这种旧的软件

因此，一些列被添加到本地计算机上的TrueDBGrid中。在测试构建产品并准备部署后，这会被推到另一台机器上。在添加所有列之后，验证更改是否使一切正常，所有内容都被推送到处理生产的计算机上

这些更改包括逻辑更改、添加额外的全局变量、修改数据环境以及其他一些小更改。将更改推送到计算机的时间是发生“内存不足”错误的时间。此外，还修改了不包含此问题的其他项目。就编译器而言，它声明错误来自user32.dll。这就是问题发生的原因

我将添加一些在下面发布答案之前尝试过的附加内容

我们阅读并尝试的事情包括验证我们认为可能是原因的所有dll都没有注册（部分原因是这台新的生产计算机最近发生了变化，并且我们的产品还没有全部建立在它之上）我还了解到，如果某个dll作为已知dll包含在注册表中，并且当某个程序试图通过其他程序访问该dll时，windows将尝试在该区域之外搜索之前使用该已知dll，这并不少见

验证所有路径是否正确以及所有dll的所有文件是否实际存在被视为一个可能的问题

验证我们是否有足够的内存来运行所有需要的东西。由于一个主要原因，这种可能性被取消了。跟踪任务管理器的性能不应出现接近最大容量的峰值

此外，我们还尝试将生产机器上的项目转移到我们的一台开发机器上，并产生了相同的问题。通过不涉及正常流程的其他方式从我们的生产机器中获取相同的代码。两者都造成了问题。这使我们相信生产机器上的某些东西是问题的真正根源

这一切都是昨天完成的，所以我可能错过了我们尝试做的一些事情，但从其他研究中，我们确实了解到，对于VisualBasic来说，为与此无关的错误抛出“内存不足”错误并不罕见

---

下面是我们如何解决这个问题的。虽然我不太确定这是如何导致问题的，我将如何再次创建它。

我们做了什么来解决这个问题

我认为，由于我们修改了数据环境，我们知道内存和全局变量很可能不是问题所在，因为我们有其他应用程序使用更多的变量或更大的变量，它们都工作得很好，但这是仍然在这里工作的人第一次修改数据环境，这是下一次试图解决问题的事情越来越少

我们将数据环境和datagrid恢复到以前的状态，并将其破坏以验证其是否工作。 它确实起了作用

基于这一点，我们修改了生产构建中的数据环境，以模仿在开发方面所做的工作，并且我们能够成功地编译

我的导师的一个想法是，在我们的开发端和现在的生产端的dll的某些级别上，版本是不同的。这导致了变化的发生方式，生产无法正确处理

---

因此，TLDR数据环境的变化导致了“内存不足”错误，这种错误在大多数机器上都能正常工作，但在其他机器上却不能正常工作。

究竟“数据环境”是什么意思？换言之，您具体更改了什么？这有点冗长，我不知道如何总结，但这里有一个链接，描述了数据环境以及它的用途。我还添加了一个编辑来包含datagrid。但是，我从开发人员计算机上创建的datagrid中删除了新列，并删除了在数据环境中创建的添加字段，以便能够保存新列的新值。在生产端，我重新创建了这些列和字段，数据环境和datagrid之外的代码都不需要更改。更详细地说，在datagrid->（用户可以在应用程序上看到的UI）和data Environment->（连接到本地mdb）中添加了8列和8个字段。