Results 1 to 5 of 5
  1. #1
    Join Date
    Feb 2002
    Posts
    11

    Unanswered: Error Accessing File. Network Connection May have been lost.

    I am using Access 2000 and received the message: "Error accessing file. Network connection may have been lost". The file is now corrupt. I have a back up but I made many changes after I made the back up. I read in the forums that Microsoft has a fix for this but it is not public.

    Does anyone know what this fix is? Microsft has an article in the knowledge base but it explains how to prevent the problem, not how to fix it.

    Please help.

    Thank you,

    Leonard Patella

  2. #2
    Join Date
    Mar 2002
    Location
    Calgary, Alberta
    Posts
    5
    Hi,

    I just had this same problem and could not resolve it on my own. So I ask the Lord for His help based on that verse in the Bible which says "If any of you lack wisdom, let him ask God who gives to all men liberally." He led me to the right resources, and the problem is solved.

    Create a new database and import all the tables, modules, queries and other objects into it. Next, open a code window and click on the Debug menu, then the compile option. Clean up all the errors you encounter either by deleting the offending code or (if you need it and it's still under construction) comment it out. When you get a clean compile, save the database and exit.

    Make a backup copy at this point (I usually create a new folder with the date as part of the name to store it in).

    This issue results from a conflict between Access and a .DLL from Office XP or Visio 2002 documented in the MS Knowledge Base. It crops up specifically as a result of importing objects from another Access database (or, in my case, from adding a class to my .MDB on the fly). That puts part of the database into a non-compiled state and generates the error. Compile and backup frequently!

    Here is the information I uncovered:

    Two ARTICLES in here: both deal with "Error Accessing File" error

    Second article has a reference to how to deal with corrupt databases in Jet 4


    Subject: INFO: The real deal on the /Decompile switch
    (Originally posted 5/22/99)
    This post is to give a little historical background and info on this undocumented command line switch in msaccess.exe. To use it, you simply run:

    msaccess /decompile <your database name>

    ************************************************** ***********************

    NOTE: in Acc 2000 I found you had to type:

    msaccess.exe /decompile (in the Start/Run box) and then pick the database you wanted to decompile. Save the database and exit when the decompile completes before attempting to work with it again.

    ************************************************** **********************************
    and thats all there is to it. But what exactly does it do?????

    VBA AND THE 11 STATES OF COMPILATION

    Thats right, internally there are 11 different compilation levels between decompiled and fully compiled like you would find in an MDE. As you make objects dirty, you will decompile the project, but dirtying Module1 does not remove all the "compiled" info about Module2 or Form1, for example. The exact levels are impossible to even detect unless you have source and debugging symbols for VBA, and insanely difficult even then.... so lets just leave it as read that the yes/no question of "is it compiled?" has many subcategories under the NO answer that essentially mean its not compiled but some parts of it are kind of.

    P-CODE VERSUS CANONICAL TEXT

    Your code is stored in two forms, each one of which is a Stream object in the project's storage(s). One form is the canonical text that you look at and edit and such, the other is the compiled version of the code that runs. VBA must always compile before it runs, so in an app that runs you will always find p-code. And unless you are running in an MDE (where the canonical code is stripped out) you will always have the canonical text too. Any time VBA thinks that the compiled code is invalid (such as when you make a change or the binary format changes, which is so far only during beta cycles), it will "decompile" the module and then compile it again from the canonical text.

    ACCESS BETAS: BINARY FORMATS, ETC.

    People who were on the betas for Access 95, 97, and/or 2000 will remember the binary format issues. From build to build, changes would be made in VBA or in the Access OM which would make old compiled code invalid. Usually a crash is the best you could expect. To help fix this, some work was done to have a global way to decompile *ALL* code that is present in a project so that you do not risk having any invalid code that might crash.

    **********
    This is the reason the flag is there and the only reason. The command line switch is undocumented because there is never a binary format change except during betas and in internal builds.... so there is no reason to document something never intended to be used.

    **********

    NOW there are some positive benefits that are side effects that people have made use of:

    1) SIDE EFFECT: CORRUPTED PROJECTS

    Now, as a side effect, you have a way to deal with corrupt projects! You see, the canonical text is never what is corrupted, it is always some compiled portion of a project, like a module or most commonly the typeinfo of a form or report. By globally telling Access that the compiled portion should be thrown away, you get rid of whatever the bogus piece of code is. Now this kind of fix is what would have taken care of the old Access 95 vba232 page faults and other problems where Access was walking off the end of a vtable and crashing, as well as a zillion other such little problems. This is what made PSS first expose this flag for.... if a project is corrupted, this is the best way to uncorrupt it.

    2) SIDE EFFECT: PROJECT SIZE

    It was found that there are times where an object would be decompiled and while the Stream object from the storage would be properly invalidated, it would be orphaned and left in the storage, and then would not be cleaned up later. There are many applications that use structured storage that have such a problem in their garbage collection... VBA/Access is just one of them, thats all. Over time, these orphaned streams will contribute some bloat to the project. People noticed that a fully compiled app would take up more space than the same app fully compiled with all objects imported to a new database..... and that is the very issue being discussed here. As you may have guessed, the /decompile switch, which invalidates *all* streams that contain compiled code, does an effective job of garbage collection and removes these orphaned streams. Thus, a /decompile /compact will make for the smallest possible size of as database.

    RISKS TO DECOMPILE: WHY YOU SHOULD NOT USE IT CONSTANTLY

    If you think about the mechanism, you are relying on the canonical text always being completely valid, and you are relying on the ability to globally invalidate a compiled state. If there is ever a problem in either area, /decompile will take a project that was working fine and turn it into cottage cheese. And while such bugs should not happen.... it is impossible to make a /decompile bug happen without using /decompile. They simply did not extensively test a command line switch that was never meant to be used.... nor should they have to, really.

    SO, PLEASE REMEMBER that this is a very powerful technique that was added for reasons having nothing to do with any of the reasons that you may want to use it now. It may help you save an otherwise hopelessly corrupted project. But use it sparingly as you may end up in a worse situation than you started by just globally using the switch on projects that do not need it.

    IF IT AIN'T BROKE, DON'T FIX IT.

    ************************************************** ********
    ************ NEW ARTICLE STARTS HERE *********************
    ************************************************** ********

    Hi Kathleen,

    My name is Eric. Thank you for using the Microsoft Access Newsgroups.

    It's very possible that you could have a corrupted module within your database file. If that is so I
    recommend using the following code to export your module (or Form or Report) out to a Text file and
    importing them back in.

    Application.SaveAsText acForm, "ObjectName", "PathToTextFile.txt" to export

    ' Manually delete the Object (e.g., Form, Report, Module) from within your database window
    Application.LoadFromText acForm, "ObjectName", "PathToTextFile.txt" to import

    note: Objects could be acForm, acReport, acModule, etc..

    -- Or -- Q209137 ACC2000: How to Troubleshoot/Repair a Damaged Jet 4.0 Database
    http://support.microsoft.com/support.../Q209/1/37.asp

  3. #3
    Join Date
    Jan 2006
    Posts
    1

    The same problem....

    In felt in this problem recently.

    I tried many things and I couldn´t resolve this. Having a better look, I discovered I named three different objects with the same name = a table, a form and a module.

    Internally, forms are name "Form_" plus the given name.

    I dragged each object from the problematic db to a new db, except the module with the same name than the table and the form. Then, after compiling, the new db worked fine.

    The code inside the module, I paste inside the form. But I am sure that I could drag the module, after renaming to a different name....

    Good luck for all...

    Roberto

  4. #4
    Join Date
    Feb 2002
    Posts
    11

    Solution

    This is a problem with certain versions of Access. Microsoft has a fix. Once you get the message though, your file is corrupted and cannot be fixed.

    Basically, you need to install a different version of MSAccess.exe.

  5. #5
    Join Date
    Oct 2010
    Posts
    4

    Error accessing file. Network connection may have been lost

    The above behavior can be witnessed in the following situations:
    The problem can occur when both Access 2000 and version 6.3.91.8 of the Vbe6.dll file are installed on a computer and when you import forms or reports that contain code modules or standalone modules into a new Microsoft Access 2000 database by using MS Access 2000. Then, you close and reopen the database and try to view, execute or compile the code.

    Due to the conflict between MS Access 2000 and version 6.3.91.8 of the Vbe6.dll file, certain code modules do not compile and run. And, the failure of the code results in the above unrelated error.
    The other reason could be database corruption

    Following is the solution:

    If yours is a computer without the version of Vbe6.dll installed, you may be able to overcome the problem by following these steps:
    1.Open a form or a report in Design view
    2.Save the code behind the form or the report as a text file
    3.Set HasModule property of the form or report to No, and then save the object
    4.You have to repeat step 1 and 3 for each form or report in database
    5.Save each module as a text file
    6.Create a new blank database
    7.Go to File menu>Get External Data>click Import. Import all tables, queries, reports and more to a new database.
    8.Restore the code behind each form and report from the text files
    9.import each text file as a new module
    If you do not have the computer without the version 6.3.91.8 of the Vbe6.dll file, you must revert to an updated backup of the database. However, in absence of a valid backup or in case of database corruption, you must consider mdb file repair options.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •