How can I fight MS Access failure?
Please see the attached image and advise how I can prevent from what used to be GPF. Any Experts' tips would be appreciated.
Access-GPF.bmp
Access-GPF.bmp
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
As indicated by others, this can be caused by many different events. Some of the more common are:
1) Dropped network connections
2) Sharing the SAME file concurrently among multiple users, especially if those users are running different versions of Access
3) Modifying code while in Break or Debug mode.
Additionally, you should make it a habit to backup your database regularly. You can do so with simple Windows keyboard shortcuts - close the database, find it with Windows Explorer, then press Ctrl + C and then Ctrl + V.
You should also Compile your work regularly. From the VBA Editor, click Debug - Compile, and fix any errors you encounter. Clean code tends to be less likely to corrupt.
As fyed mentions, importing into a new database container will almost always clear up corruption, but it is possible to import a corrupt Form or Report. If that happens, the only thing you can do is recreate that form, either from scratch or from a recent known-good backup.
1) Dropped network connections
2) Sharing the SAME file concurrently among multiple users, especially if those users are running different versions of Access
3) Modifying code while in Break or Debug mode.
Additionally, you should make it a habit to backup your database regularly. You can do so with simple Windows keyboard shortcuts - close the database, find it with Windows Explorer, then press Ctrl + C and then Ctrl + V.
You should also Compile your work regularly. From the VBA Editor, click Debug - Compile, and fix any errors you encounter. Clean code tends to be less likely to corrupt.
As fyed mentions, importing into a new database container will almost always clear up corruption, but it is possible to import a corrupt Form or Report. If that happens, the only thing you can do is recreate that form, either from scratch or from a recent known-good backup.
ASKER
...you should make it a habit to backup
Boring...and useless,
I am already a good boy :-)
Boring...and useless,
I am already a good boy :-)
ASKER
Seriously,
I use VSS and previous releases as my backup. As to importing it sounds good, and of course I tried it. However I have to realize the risk of losing something from mysterious Data and Misc. Objects domain. How can I import all of the below:
...
I use VSS and previous releases as my backup. As to importing it sounds good, and of course I tried it. However I have to realize the risk of losing something from mysterious Data and Misc. Objects domain. How can I import all of the below:
...
Relationships
User-defined command bars
Import export specs
Database properties, startup properties
Visual Basic for Applications project references
The Visual Basic for Applications project name
Conditional compilation arguments
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Well, I am ready to learn, sorry. It looks like a good idea to accompany a question with something like "I am working with MS Access [.Net, SQL], since v1.0"
As to VSS-related corruption, I heard about it many times. I never got a chance to reproduce this kind of disaster (although maybe this is what I am dealing with now) so I am not sure whether I can somehow use this information. My credo is: MS Access application is what is stored in VSS and can be easily generated in form of MDB file. The purpose of the latter is predominantly to be fixed and then to update VSS. Sometimes a new release goes from VSS as well.
The whole story is as follows.
I generated MDB on my development workstation (XP, Access 2007) from VSS, made changes in forms' code checked everything in, then built MDB again, removed VSS from it and put it on testing server (Windows Server 2003 R2, Access 2003 -- works for years). The forms that I modified -- and only them -- cause intermittently Access failure on testing server.
Other multitudinous functions seem to work fine.
I'll build it again, but I had a hope anybody might point me in a more productive direction.
As to VSS-related corruption, I heard about it many times. I never got a chance to reproduce this kind of disaster (although maybe this is what I am dealing with now) so I am not sure whether I can somehow use this information. My credo is: MS Access application is what is stored in VSS and can be easily generated in form of MDB file. The purpose of the latter is predominantly to be fixed and then to update VSS. Sometimes a new release goes from VSS as well.
The whole story is as follows.
I generated MDB on my development workstation (XP, Access 2007) from VSS, made changes in forms' code checked everything in, then built MDB again, removed VSS from it and put it on testing server (Windows Server 2003 R2, Access 2003 -- works for years). The forms that I modified -- and only them -- cause intermittently Access failure on testing server.
Other multitudinous functions seem to work fine.
I'll build it again, but I had a hope anybody might point me in a more productive direction.
ASKER
I acknowledge my fault that lead to miscommunication.
I sincerely apologize.
I sincerely apologize.
The symptoms you describe are what I experienced when trying to deal with Access on VSS - that is, it worked okay, but I had quite a few issues with corrupt objects coming out of VSS.
No mention of VSS in the original post, but when the OP referenced VSS, it reminded me of the thread from last week when someone was asking about a source safe type solution for Access. Scott, I recalled that either you or Joe had piped up about "difficulties" with VSS.
I generally start out every session by saving the current file to a new file name, and working with that copy. If everthing works well, I just use that as the baseline for my next session. I tend to keep about a weeks worth of these backups (on a separate computer) just in case.
I generally start out every session by saving the current file to a new file name, and working with that copy. If everthing works well, I just use that as the baseline for my next session. I tend to keep about a weeks worth of these backups (on a separate computer) just in case.
ASKER
The question was not about VSS, which BTW, has its own problems, but about MS Access.
I remember a complex form with many subforms on it that was absolutely untouchable (see above) until I changed its record source from <table name> to select * from <table name>. After that I could make changes and test it. It took a good deal of time to guess...
Yeah,... it's about Access.
I remember a complex form with many subforms on it that was absolutely untouchable (see above) until I changed its record source from <table name> to select * from <table name>. After that I could make changes and test it. It took a good deal of time to guess...
Yeah,... it's about Access.
ASKER
Well, every now and then. Both on 2003 and 2007. Circumstances vary. E.g., now I am working with a form's code and when I test it in Form view, Access may or may not fail as on my image.
Does the error come up every time?
It just became too obtrusive.
And,... yes, I tried "Compact & Repair", /decompile, rebuild from VSS
Has this database been in use for a long time without this problem?
The database exists in VSS for about 10 years. It is a working application but sometimes for some reasons its instance (or one of MS Access objects??) becomes "untouchable".