如何诊断MS访问崩溃

时间:2013-06-24 15:32:34

标签: ms-access access-vba

我们有一个用Access编写的自定义程序,其中包含奇怪的崩溃。我们添加了错误处理,记录并通过电子邮件发送在我们自己的代码中发生的任何崩溃,这使我们能够修复我们生成的大多数错误,但有时崩溃发生在我们的代码之外。

我们发现在2013年出现新版本的一个示例 - 我们有一个在某个字段中编辑数据后会崩溃的表单 - 新条目很好但创建记录后的任何编辑都会导致完全崩溃并关闭MS Access。我们花时间并最终追踪到我们的一些代码迫使表单移动到下一个记录,这个字段是行中的最后一个字段,所以Access本身也试图移动到下一个记录。这是自2007年以来一直在系统中,但在2013年开始导致程序关闭。

有没有办法陷阱和诊断MS访问中的程序级崩溃?
Windows事件查看器仅显示以下内容:

错误应用程序名称:MSACCESS.EXE,版本:15.0.4454.1501,时间戳:0x50a35ef4 错误模块名称:MSACCESS.EXE,版本:15.0.4454.1501,时间戳:0x50a35ef4 异常代码:0xc0000005 故障偏移:0x00116452 错误进程id:0x1398 错误应用程序启动时间:0x01ce6e665043d8be 错误应用程序路径:C:\ Program Files(x86)\ Microsoft Office \ Office15 \ MSACCESS.EXE 错误模块路径:C:\ Program Files(x86)\ Microsoft Office \ Office15 \ MSACCESS.EXE 报告ID:6cfcb0eb-da62-11e2-8966-842b2b86f028

6 个答案:

答案 0 :(得分:15)

这是一个老线程,但它是谷歌的最佳成果之一,所以我想我会给出答案。当你得到" Access遇到问题并需要关闭时,你可以采取什么步骤?通常在事件日志中,您将看到:

Faulting application name: MSACCESS.EXE, version: 15.0.4869.1000, time stamp: 0x57e12b41
Faulting module name: MSACCESS.EXE, version: 15.0.4869.1000, time stamp: 0x57e12b41
Exception code: 0xc0000005

排除故障可能令人沮丧。以下是我采取的行动清单,从最少侵入性到最具侵入性。我不只是发明了这些修复 - 多年来我亲眼目睹了每个修复解决问题。

反编译数据库

您表示反编译每个版本是一项政策。良好的政策 - 但每次出现错误后都要明确地做。原因是因为您可能正在修复核心问题,但由于容器损坏而无法注意到。

  • 我创建了一个快捷方式,使用" / decompile"加载数据库。开关。
  • 双击此快捷键时按住shift键,以便跳过任何自动运行并直接进入导航窗口。
  • 加载数据库后,您需要单击“压缩和修复”按钮。在数据库重新加载时再次按住shift。
  • 现在去编译代码并保存。这是我用于反编译的过程。

测试计算机内存

特别是如果碰撞仅限于一​​台或两台机器 - 请执行此操作 检查事件查看器。有不少"错误"描述应用程序崩溃的消息,错误模块是不同的?如果是这样,那么如果不是安装了损坏的Windows,那么几率很高,你会看到一个内存问题。

我确信有很多优秀的内存测试人员,但我鼓励你使用一个能够捕获丢失位的正确测试。 MemTest86是一个老人,但是一个好东西。有current version和一些同样好forks

开始测试并让它在工作时间运行。我在建筑物中的功率不好会导致内存错误,所以保持变量不变。

从表单中删除二进制数据

有时崩溃发生在单个表单或报表中。如果它是损坏的二进制数据,那么崩溃应该发生在具有不同用户的不同计算机上。如果是这种情况,请按照以下步骤操作。 (仅限高级用户)

  1. 在即时窗口中将对象另存为文本。

    Application.SaveAsText acForm," MyForm",CurrentProject.Path& " \ MyForm.txt"

  2. 重命名原始表单项(例如重命名为MyForm_Bak)

  3. 在记事本中打开导出的文件
  4. 删除" Checksum ="线(应该在第3行)
  5. 清除二进制数据
    • 浏览文件。
    • 会有以&#34开头的行;参数=开始"并且包含编码二进制数据行,以包含"结束"
    • 的行结束
    • 当您找到其中一行时,您需要(包含)删除从Begin到End的所有行。
    • 您应删除的参数有:NameMap,PrtMip,PrtDevMode,PrtDevNames,PrtDevModeW,PrtDevNamesW
    • 所有这些块应该出现在窗体控件定义
    • 之前
  6. 当您打开文件时,滚动文件的其余部分并查找引起您注意的任何内容,尤其是底部的VBA模块代码。
  7. 保存文件
  8. 在Access中,在即时窗口中,将表单重新加载到

    Application.LoadFromText acForm," MyForm",CurrentProject.Path& " \ MyForm.txt"

  9. 反编译/精简修复/重新编译

  10. 打开表单,希望一切都运行得更好。
  11. 摆脱" OLE对象"领域

    如果您在Access中存储了图像或其他数据,那么您应该找到更好的方法。存储OLE数据时,根据存储它的计算机上的软件(和软件版本)存储它。当另一台计算机在窗体上显示OLE对象数据但没有安装确切的软件/版本时 - 你经常会崩溃。

    如果要存储图像数据,则更好的方法是存储文件名,而不是将图像保存到标准位置。较新版本的访问具有本机控件,可以实现这一目标。

    重建整个数据库

    这是很多工作,所以当你用完所有其他选项时我会保存这个。如果所有用户都出现问题,则只需执行此操作。如果并非所有用户都发生这种情况,那么它就不是一个损坏的数据库。

    与删除二进制数据的步骤类似,您将从头开始重建数据库。当我到达这一步时,我处于全偏离模式。也许它有点仪式化,但我一丝不苟地做了一切,没有做任何捷径和非常谨慎,而不是保持"通过直接复制或导入/导出的腐败。作为我的最后一个立场,我认为这无法解决这个问题。值得庆幸的是,自Access 2000以来,我不得不这样做。

    • 创建新的访问数据库容器。
    • 请勿使用导入/导出功能
    • 表:
      • 对于旧访问容器中的每个表,在新容器中创建一个新表。从设计视图中,复制/粘贴字段定义。
      • 将旧数据导出为XML或CSV,然后从那里导入。
    • 查询:
      • 进入原始查询的SQL视图,将SQL文本复制并粘贴到新数据库的查询中。
    • 表格/报告:
      • 使用Application.SaveAsText函数导出表单/报告
      • 从表单中删除二进制数据并查看
      • 使用Application.LoadFromText函数重新导入它们
      • 重新创建宏。
      • 在Access 2007及更高版本中,使用新的Macro系统,您只需打开宏,全选(Control + A)并粘贴到空白的记事本文档中。从记事本中再次复制并粘贴到新访问容器中的空白宏
    • 模块
      • 选择所有代码(Control + A)并粘贴(Control + V)到新数据库容器
    • 数据宏
      • 由于数据宏已经问世,我不得不这样做,但您可以使用SaveAsText / LoadFromText函数从表中导出数据宏。

    完成所有操作后 - 您应该拥有一个非常干净的数据库容器。

    从测试中删除其他变量

    网络损坏

    请勿将客户端从网络加载。把它放在本地驱动器上并从那里运行它。

    企业建设

    如果您所处的公司环境正在使用"计算机构建"并且在反编译,测试内存和剥离二进制数据方面没有成功 - 然后拒绝进行进一步测试,直到IT团队可以为用户提供仅安装了Windows,Office和Service Pack的测试计算机。我通常喜欢自己安装,所以我知道我可以相信它。应手动安装所有软件和更新,而无需使用无人参与安装。请勿在此计算机上安装防病毒软件。

    我让IT部门拒绝接受F.U.D.并且不合理 - 如果这是你遇到的问题,那么请在#34;帮助我帮助你清洗你的问题"上下文。

    电力不足

    如内存部分所述 - 电源波动可能导致计算机错误。如果数据库位于工业建筑中 - 那么请尝试使用电源调节器或提供清洁电源的UPS(关闭电池,而不是通过金属氧化物压敏电阻从主电源开关)

    另外,检查插入电源插座或插座的电源线。确保仪表和电压规格足够。我之所以这么说,是因为IT部门经常将电源线插入工作站,只需将机器拆下即可。多年以后,他们正在使用更强大的电源,但没有关闭电缆。它有所作为。如有疑问,请带上一根新的,更粗的电缆。

    <强>附录

    自从最初发布这个以来,我遇到了一些新的。多次遇到我的是移动到Access 2016时的ODBC驱动程序。如果您的数据库在Access 2013下工作正常,但在Access 2016中可靠地崩溃,那么问题可能是ODBC驱动程序。跳一跳,试着找出是否有更新的驱动程序。如果没有成功,则通过创建新数据库并在VBS中进行ODBC调用来确认它是否是ODBC驱动程序。如果你得到同样的崩溃 - 它的驱动程序。如果没有更新的驱动程序,您只需将其保留在2013年。我在PostGreSQL ODBC驱动程序中遇到了一些数据库。

答案 1 :(得分:3)

每个Access数据库中每个表单上的每个函数都应该有一个如下所示的流:

Private Sub btnMyButton_Click()
Dim MyVar as String
On Error GoTo ErrorHappened

'Do some stuff here...

ExitNow:
    Exit Sub

ErrorHappened:
    MsgBox Err.Description
    Resume ExitNow
End Sub

在ErrorHappened部分中,您可以将其写入跟踪错误的表。如果您将所有子功能和功能更改为这样,您应该能够捕获数据库的每个问题。也许写出Err.Number以及Err.Description。

答案 2 :(得分:1)

对于在Google中遇到这个帖子的其他人来说,这是导致随机访问崩溃的另外两个原因:

仅仅为了背景,我有一个带有子表单的表单,从服务器上的链表加载数据。

  • 如果在父窗体上的字段上有“_Enter”事件,则可能导致Access进入无限循环,重复触发这些事件。当我在子窗体上并按下父窗体上的按钮时发生这种情况。我用“_GotFocus”事件替换了所有这些,而不是修复了问题。

  • 即使是父窗体,也不要引用onLoad中的子窗体。这个是随机的,表单将加载正常,然后下次你进入相同的表单,具有相同的记录,它将导致访问崩溃。所以我删除了父窗体的onLoad事件中对子窗体的所有引用,现在它似乎工作正常。我特别注意到这一点,当我的互联网连接速度很慢时,似乎主要表单是在子表单之前加载的,所以当它引用它时它没有加载,因此导致了各种各样的Access问题,这种问题在随机崩溃中结束访问。

答案 3 :(得分:1)

2020更新和其他答案。 我最初尝试升级到2019 Pro的最初创建于2010年的应用程序出现了相同的“打开宏时崩溃”的随机问题。这是解决问题并帮助自己的一种简单方法...清理应用程序。 将Access应用程序从较早版本升级到2019 Pro或更高版本时,请删除所有及所有开发表,查询,宏,表单,在应用程序中不使用的任何内容...旧的,过时的,任何地方,检查应用程序中的所有位置以及摆脱它!问题已解决,您的应用现在变得更整洁,更易于维护...非常适合我们的升级情况。

答案 4 :(得分:0)

我使用Access 2010。 通过转到文件->将对象另存为->表单名称为REPORT,我制作了一个报告(给定表单的真实副本)。 在设计视图中打开报表时,进行一些更改后,我尝试保存更改。访问不断崩溃。 几个小时后,我终于发现报告中包含一些按钮。当我将它们替换为控制箱时。就是这样一切都很好。 希望这可以节省一些人的宝贵时间,并且没有任何寻找的迹象。

答案 5 :(得分:0)

检查str()函数调用。 从2010-> 2019更新后,有时此调用会崩溃。