2013-06-24 67 views
9

我們有一個用Access編寫的自定義程序,它有奇怪的崩潰。我們添加了錯誤處理功能,記錄和發送在我們自己的代碼中發生的任何崩潰事件,這使我們能夠修復我們生成的大多數錯誤,但有時崩潰發生在我們的代碼之外。如何診斷MS訪問崩潰

我們發現在2013年發現了一個新的例子 - 我們有一個表單會在編輯某個字段中的數據後崩潰 - 新條目很好,但創建記錄後的任何編輯都會導致完全崩潰並關閉MS Access。我們花了很多時間並最終追蹤到我們的一些代碼強制表單移動到下一個記錄,這個字段是行中的最後一個字段,儘管Access本身也試圖移動到下一個記錄。這個系統自2007年以來一直在系統中,但在2013年開始導致程序關閉。

有沒有什麼方法可以捕獲和診斷MS訪問中的程序級崩潰?
Windows事件查看器只顯示以下內容:

錯誤的應用程序名稱:MSACCESS.EXE,版本:15.0.4454.1501,時間戳:0x50a35ef4 錯誤模塊名稱:MSACCESS.EXE,版本:15.0.4454.1501,時間戳:0x50a35ef4 異常代碼:0000005 故障偏移: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-89 66-842b2b86f028

回答

5

這是一個古老的線索,但它作爲谷歌的頂級成果之一,所以我想我會給一個答案。當您收到「訪問遇到問題並需要關閉」時,您可以採取哪些步驟?通常在事件日誌中你會看到:

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. 導出的文件
  5. 刪除「校驗=」行(應該是在第3行)
  6. 清除出二進制數據
    • 查找通過文件。
    • 將會出現以「參數=開始」開始並具有編碼二進制數據行的行,以包含「結束」的行結尾
    • 當您找到這些行中的一行時,您將需要(包含性地)刪除從開始到結束的所有行。
    • 您應該刪除的參數是:NameMap,PrtMip,PrtDevMode,PrtDevNames,PrtDevModeW,PrtDevNamesW
    • 所有這些模塊都應該出現在你的表單控件定義
  7. 當你打開該文件,滾動文件的其餘部分,並尋找任何引人注目的東西,特別是在底部的VBA模塊代碼中。
  8. 保存文件
  9. 在Access,即時窗口上,加載形式早在

    Application.LoadFromText acForm, 「MyForm的」,CurrentProject.Path & 「\ MyForm.txt」

  10. 反編譯/緊湊修復/重新編譯

  11. 打開窗體並希望一切都工作得更好。

擺脫「OLE對象」字段

如果你的圖像或存儲在訪問本身,那麼你應該找一個更好的方法等數據。當存儲OLE數據時,它將根據存儲它的計算機上的軟件(和軟件版本)進行存儲。當另一臺計算機在窗體上顯示該OLE對象數據時,卻沒有安裝確切的軟件/版本 - 您經常會發生崩潰。

如果您要存儲圖像數據,則更好的方法是存儲文件名,然後將圖像保存到標準位置。較新版本的訪問具有本地控制,以實現這一目標。

重建整個數據庫

這是一個大量的工作,所以我會保存這個當你用盡所有其他選項。如果所有用戶都遇到問題,則只需執行此操作。如果不是所有用戶都在使用,那麼它不是一個損壞的數據庫。

與刪除二進制數據的步驟類似,您將從頭開始重建數據庫。當我到達這一步時,我處於全部偏執狂的模式。也許它有點儀式化,但我一絲不苟地做一切事情,沒有捷徑,非常小心,不要通過直接複製或導入/導出來「維護」腐敗。作爲我的最後一個立場,我認爲這從未解決過這個問題。謝天謝地,自從Access 2000開始,我就不必這麼做了。

  • 創建一個新的訪問數據庫容器。
  • 不要使用導入/導出功能
  • 表:
    • 對於每個表在舊接入容器,新容器創建一個新表。從設計視圖中,複製/粘貼字段定義。
    • 將舊數據導出爲XML或CSV,然後從那裏導入。
  • 查詢:
    • 走進SQL視圖在原來的查詢,複製並粘貼SQL文本到新數據庫的查詢。
  • 表單/報表:
    • 使用應用程序。SaveAsText功能導出表單/報表從形式
    • 地帶的二進制數據和審查
    • 使用Application.LoadFromText功能重新導入
    • 重新創建的宏。
    • 在Access 2007及更新版本中,使用新的Macro系統,您可以簡單地打開宏,選擇全部(Control + A)並粘貼到空白的記事本文檔中。再從記事本並粘貼到新的接入容器
  • 模塊
    • 內的空白宏選擇所有代碼(控制+ A)並粘貼(Ctrl + V組合)到新的數據庫容器複製
  • 數據宏
    • 我還沒有做到這一點,因爲數據宏已經出來了,但你會使用SaveAsText/LoadFromText功能將數據導出宏關閉表。

當一切都說過和做過 - 你應該有一個非常乾淨的數據庫容器。從測試

刪除其他變量

網絡損壞

不要加載客戶端斷網。把它放在本地驅動器上並從那裏運行。

企業構建

如果您在使用「計算機建立」,並曾與編譯,測試內存沒有成功,和剝離二進制數據的企業環境 - 然後拒絕做進一步的測試,直到IT團隊可以爲用戶提供僅安裝了Windows,Office和Service Pack的測試機器。我通常更喜歡自己做安裝,所以我知道我可以信任它。所有軟件和更新都應手動安裝,而無需使用無人蔘與的安裝。不要在這臺機器上安裝防病毒軟件。

我曾有IT部門拒絕這個純粹的F.U.D.不合理 - 如果這是您遇到的情況,請在「幫助我幫助您」背景下解決問題。

實力不濟

由於在存儲部分中提到的 - 電力fluctations可能會導致計算機錯誤。如果數據庫位於工業建築物中 - 那麼試着將手放在提供清潔電源的電源調節器或UPS上(關閉電池,不要通過金屬氧化物壓敏電阻主體)

另外,檢查電源線插入電源杆或插座。確保規格和電壓規格足夠。我這樣說是因爲IT部門經常會在電臺上插入電源電纜,並且只是移除機器。多年後,他們正在使用更強大的電源,但沒有切斷電纜。它有所作爲。如有疑問,請帶一根新的較厚的電纜。

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。

+0

我們使用與此非常相似的錯誤捕獲 - 一些錯誤似乎發生在我們的代碼之外,並且在微軟的代碼中,因此它跳過了我們的錯誤處理。我試圖確定一種有效的方法來解決在我們的代碼之外發生的崩潰(它們仍然可能是由我們的代碼引起的,但我們完全完成並且_then_發生崩潰) –

+1

您的代碼是否已編譯?您是否嘗試使用-decompile開關反編譯它,然後重新編譯它? –

+0

我們已經做到了。我們的政策是在每次發佈時都要進行反編譯和重新編譯。我上面說明的崩潰是典型的 - 在Access試圖移動到下一個記錄的同時,我們移動到下一個記錄的某個實例使整個程序崩潰。我們只是通過消除計算出來的,除了我在第一條評論中粘貼的窗口級別錯誤之外,沒有給出任何錯誤編號。 –

1

對於誰比誰在谷歌跨過這個線程絆倒這裏是另一個隨機訪問崩潰幾個原因:

只爲背景,我有上有一個子窗體形式,從一個鏈接表加載數據服務器。

  • 如果您對父域「_Enter」事件的形成,這可能導致訪問進入無限循環,重複地觸發這些事件。當我在子窗體上時發生這種情況,並在父窗體上按下按鈕。我用「_GotFocus」事件取代了所有這些,而修復了問題。

  • 不要在onLoad甚至父窗體中引用子窗體。這是隨機的,表單會加載正常,然後當你下一次進入相同的表單時,使用相同的記錄,它會導致Access崩潰。所以我刪除了父窗體的onLoad事件中對子窗體的所有引用,現在看起來工作正常。我特別注意到這一點,當我的互聯網連接速度很慢時,似乎主窗體在子窗體之前加載,所以當它引用它時,它沒有加載,所以導致Access出現各種問題,這些問題以一個隨機崩潰結束的訪問。