dao350.dll 会在内存中损坏并损坏新连接吗？

Posted 2023-04-18

【中文标题】dao350.dll 会在内存中损坏并损坏新连接吗？

【英文标题】：Can dao350.dll get corrupted in memory and corrupt new connections?

【发布时间】：2016-05-16 13:14:18

【问题描述】：

我们正在尝试解决涉及 Access 数据库连接的问题。数小时或数天一切正常。然后一个程序得到一个页面错误错误。之后，网络上的每个程序都无法与其访问数据库通信，直到每个使用访问的程序都被关闭。

程序是 VB6（是的，我知道）。

他们通过引用使用DAO350.dll：

dao2535.tlb#Microsoft DAO 2.5 对象库

似乎我们在内存中有孤立的 dll - 它们不属于某个进程。

看图。

有人遇到过吗？如果有，你是怎么解决的？

我们的程序在 Server 2012 上运行（如果有帮助的话，这似乎是唯一发生这种情况的系统）。

如果能在这方面得到任何帮助，我将不胜感激。

谢谢。

【参考方案1】：

首先，请不要为使用旧代码而道歉。

我仍然可以用 vb6 甚至 vb5 做一些我们今天拥有的任何新的“锁定”丑陋语义东西几乎不可能完成的事情。

我的猜测是您在未正确终止的代码中声明记录集。

解释一下，

vb5 和 vb6 总是声称私有变量或过程变量在过程完成时超出范围。

但是，对于记录集变量，情况并非如此。

假设如下

Dim dbs as database
Dim rst as recordset
dim sSQL$

Set dbs = CurrentDb

sSQL = "SELECT * FROM TBL_NAME"
Set rst = dbs.openrecordset(sSQL)

    ... Do Things

Set rst = Nothing
Set dbs = nothing

因此，我们假设 rst 超出范围（关闭，释放内存）。

没有！

一个必须肯定地关闭第一个对象

rst.Close: Set rst = Nothing
Set dbs = Nothing

否则内存被占用，尽管是孤立的。

随着时间的推移，这会产生“内存泄漏”。当内存被重新使用时，它会导致您描述的问题。有点像动脉​​阻塞导致心脏病发作。

您应该检查代码以确保所有 rst 对象（包括 rst 克隆）都已关闭。

这假设您没有使用 API 来移动内存。这也可能导致类似的问题，但我怀疑它们会随着时间的推移而累积（如心脏病发作）。移动记忆问题更像是肠道中的小刀，而不是心脏病发作。它们会立即发生并且更容易找到。

第，

加里