Results 1 to 6 of 6
  1. #1
    2 Star Lounger
    Join Date
    Jul 2002
    Location
    Sacramento, CA
    Posts
    193
    Thanks
    3
    Thanked 1 Time in 1 Post

    Network Recovery (2002 10.4302.4219 SP-2)

    I have an application in which all the tables reside in a database on a server and all the forms, reports, etc. are in their own database with the tables linked in. Each user has their own copy of the forms/reports database on their local computer.

    Today, one user was using the application and someone else started a server back-up. Minutes later while the Access application user was attempting to add a new record to the database, her system hung (guessing it had something to do with the back-up as the application has not crashed in over two months of testing) and had to be restarted. Upon restart the record she was attemtping to create was not there, but a corrupted record was. I removed the corrupted record after checking the related tables. When the Access application was restarted, the form which supports the table that had the corrupted record will not now allow any changes or additions through the form (I can update the table directly by opeing it and all other tables can be updated through the forms - even tables related to the table with the corrupted record). Tried the same procedure on another machine that did not have the Access application running at the time of the application crash (and as mentioned before, this machine has its own separate copy of the forms/report database). I get the same result here, can't add or update recoreds to the table that had the bad record. I restored the data database from the prior day's backup, and everything works fine. So apparantly there is something wrong with the 'current' data database. I've tried Repair/Compress with no change. I've run all the integrety checks I can think of and found nothing wrong (all the tables are set with Maintain Relational Integrity).

    Has anyone experience anything similar? And if so did you find a solution? Also I would have thought that the server back-up process would have skipped over the data database, but apparantly it didn't. The user is going to drop back to the yesterday version of the tables and reenter all of today's updates. But would appreciate any advice or insight anyone can share for future reference.

    Thanks much,
    Marty

  2. #2
    Plutonium Lounger
    Join Date
    Mar 2002
    Posts
    84,353
    Thanks
    0
    Thanked 29 Times in 29 Posts

    Re: Network Recovery (2002 10.4302.4219 SP-2)

    Access is extremely sensitive to hickups in the connection between the user and the database; making the backup apparently caused the database to become locked during the writing of a record. Moral of the story: don't make a backup while somebody is using the database. (You probably wouldn't have problems if users were just browsing, not editing, but it is better to be on the safe side.)

  3. #3
    Super Moderator
    Join Date
    Aug 2001
    Location
    Evergreen, CO, USA
    Posts
    6,623
    Thanks
    3
    Thanked 60 Times in 60 Posts

    Re: Network Recovery (2002 10.4302.4219 SP-2)

    Adding to Hans' comments, Access databases are multi-user by default, so as long as nobody actually has the file exclusively locked, the backup process will not skip the file. One thing you might try with the apparently corrupted database is to simply import all of the tables into a new empty database. That will often either identify problems that compact and repair doesn't, or fix the problem. The fact that you can update the table in question at the table level, but not using the form is certainly a mystery however.
    Wendell

  4. #4
    2 Star Lounger
    Join Date
    Jul 2002
    Location
    Sacramento, CA
    Posts
    193
    Thanks
    3
    Thanked 1 Time in 1 Post

    Re: Network Recovery (2002 10.4302.4219 SP-2)

    Thanks for your comments. Of course I find getting everyone in a user's office to follow simple guidlines to be an ongoing challenge.

    Marty

  5. #5
    2 Star Lounger
    Join Date
    Jul 2002
    Location
    Sacramento, CA
    Posts
    193
    Thanks
    3
    Thanked 1 Time in 1 Post

    Re: Network Recovery (2002 10.4302.4219 SP-2)

    I'll give that a try. I've used it successfully in the past (particularly with 97 on forms/reports dbs, but didn't think to try it with just the data table db.

    Thanks for the reminder,
    Marty

  6. #6
    2 Star Lounger
    Join Date
    Jul 2002
    Location
    Sacramento, CA
    Posts
    193
    Thanks
    3
    Thanked 1 Time in 1 Post

    Re: Network Recovery (2002 10.4302.4219 SP-2)

    As it turns it it was not a sever backup problem at all but a Write Conflict problem to which the User selected Save from among the three options provided by Access. Yesterday ran across the Write Conflict situation with the user. Did some testing on the response choices. Drop changes works great, a Save trashes the current record and corrupts the table just as in the first incident. Tracked down the places where code is updating the sub forms and inserted either a acCmdSaveRecord or subform.refresh. Have not been able to recreate the problem since.

    None the less, thanks again for your help,
    Marty

Posting Permissions

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