Problem with database I think I just corrupted it some how

[ShaunG]

I was doing some minor alterations - inserting a backdoor access point as I have security access levels.



after I had created the button and code on a form I seemed to have issues.

it has created a table for errors which i will attached.

it has also just come up with an error - visual basics corrupt.

i can access tables and querys but not any of my forms it comes up with this error when either clicking on forms in either visual basics or not - "id" is not an index in this table. also this code - error accessing file. network connection may have been lost

im hoping there is an easy fix, does this look like my whole database is corrupted...... if so can i import every thing into new database or will i lose data or code?

if some one can help would be very much appreciated

[ShaunG]

the table of errors ms access created

[Micron]

I would first copy this db. Then try a compact/repair on the copy and see what happens. If that fixes it, you could try it on the original as long as you open it exclusively.
Alternatively, you could try importing all objects into a fresh db and see what happens. It's generally considered wise to turn off Name Autocorrect in Options.

You are not opening this db over wifi are you?

[ShaunG]

I would first copy this db. Then try a compact/repair on the copy and see what happens. If that fixes it, you could try it on the original as long as you open it exclusively.
Alternatively, you could try importing all objects into a fresh db and see what happens. It's generally considered wise to turn off Name Autocorrect in Options.

You are not opening this db over wifi are you?

thanks Micron, I have tried copying the db and compact and repair and it didn't change anything. I tried importing but only tables and querys imported but still had same errors when opened.

no we are not opening over wifi

why is the autocorrect wise to turn off?

Our computer tech just happened to rock up to do some work here on other computers and he found a shadow copy of the database that was from last night, so I am able use that copy and just reinsert todays data again last resort.

[isladogs]

I agree with Micron re copy database (so you have a backup) & try compact & repair (though I doubt that will fix it)
Before copying to a new database, 2 other things you should try:

a) repairing errors in MSysObjects - see https://www.access-programmers.co.uk...d.php?t=293579

b) decompiling the database to remove any corrupt compile code: http://www.fmsinc.com/microsoftacces.../decompile.asp
Then recompile & compact again
That almost always works for me.

If not, then copy to a new database

[Micron]

this is old info, but many of us stick by it anyway. I suppose if we took the time to test all the known issues again after all these years, but the incentive is missing
http://allenbrowne.com/bug-03.html
You should make 1 or more copies of this backup before you again try to make the same modifications as what may have corrupted your db.

Compiling may work. Wondering why you didn't elect to import all the forms/reports into your new db. Consider suspending any autoExec macro or default db form from opening in case one or both of those is compounding the issue, then reinstate once operating normally (if possible). If you can link this resurrected db to the other tables, you could probably append/update from today's data into the new db.

If your db isn't split, this is one of the many reasons to do so. Design development is done in the front end, data is kept in the back end. Then a corrupted front end rarely results in data loss or present a problem for getting at the data.

[ShaunG]

I agree with Micron re copy database (so you have a backup) & try compact & repair (though I doubt that will fix it)
Before copying to a new database, 2 other things you should try:

a) repairing errors in MSysObjects - see https://www.access-programmers.co.uk...d.php?t=293579

b) decompiling the database to remove any corrupt compile code: http://www.fmsinc.com/microsoftacces.../decompile.asp
Then recompile & compact again
That almost always works for me.

If not, then copy to a new database

I did try this ridders52 and had no luck.... thanks for the information I tried the Decompiling and looked into repairing errors but believe I tainted it beyond repair unfortunately.

from this is it worth storing all the vba code in a different database, then the database with the tables, querys and forms?

[ShaunG]

this is old info, but many of us stick by it anyway. I suppose if we took the time to test all the known issues again after all these years, but the incentive is missing
http://allenbrowne.com/bug-03.html
You should make 1 or more copies of this backup before you again try to make the same modifications as what may have corrupted your db.

Compiling may work. Wondering why you didn't elect to import all the forms/reports into your new db. Consider suspending any autoExec macro or default db form from opening in case one or both of those is compounding the issue, then reinstate once operating normally (if possible). If you can link this resurrected db to the other tables, you could probably append/update from today's data into the new db.

If your db isn't split, this is one of the many reasons to do so. Design development is done in the front end, data is kept in the back end. Then a corrupted front end rarely results in data loss or present a problem for getting at the data.

Old info is all you need sometimes, ill look straight into so thanks.

I think you just anwsered my question above in post #7 about separating databases, in not hundred % on how to do that if theres any better ways to go about this im opened to suggestions

[ShaunG]

am I able to copy forms that will not open, to a previously backed up database or will the corruption follow with the copy?

[ssanfu]

Were you single stepping through the code while editing the code? I found out the hard way that single stepping through the code and making changes to the code is a good way to corrupt the VBA project. The VBA project is the part of the dB that holds all of the VBa you write. When that goes bak, you get the type of errors you reported.


Took me a week to figure this out.
What I did was:
1) You should ALWAYS make back ups. (the 3 rules of computing are 1) Backup...2) Backup... and 3) you guessed it BACK-UP!!)
2) I opened a copy of the corrupt dB by holding down the shift key.
3) If you can open the IDE and see the VBA form module code, copy the code from each form and paste it into a text file (one text file for one form). Save the text file with the name of the form.
4) Provided you can open the forms in design view, open EACH form (one at a time), open the properties dialog box, click on the "Other" tab and set the property "Has Module" to NO. Close and save the form. This will delete the VBA project from that form.
5) Once all of the form modules are gone, if you can open the standard modules, open then (in design mode), copy all of the code and paste the code into a text file. I named the text file the same as the module name. Then delete the code module.
6) Once all of the modules have been deleted, create a NEW dB and copy the tables, queries, forms ( be careful to NOT copy a corrupt form, do a "Compact and Repair" after each object import) and reports. Do not copy the modules or you will have a corrupt VBA project again.
7) Again, do a "Compact and Repair" on the NEW dB.
8) Now the tedious part. If you were able to copy the VBA from the corrupt dB (if not, copy the code from a backup dB) and paste it back into each form.
a) Open EACH form (one at a time), open the properties dialog box, click on the "Other" tab and set the property "Has Module" to YES. Then open the text file for that form, copy the code and paste it into the form module.
9) Create NEW modules, rename them to the correct names, copy the code from the text files and paste into the modules.

Now, in the IDE, do a "Compile", then save the IDE (use the diskette icon or CTL-S).
In Access , do a "Compact and Repair". Close the dB, then open it. Open the "Main Menu" or whatever you call the first form that opens.

Hopefully, you have a working dB now.

[ShaunG]

Were you single stepping through the code while editing the code? I found out the hard way that single stepping through the code and making changes to the code is a good way to corrupt the VBA project. The VBA project is the part of the dB that holds all of the VBa you write. When that goes bak, you get the type of errors you reported.


Took me a week to figure this out.
What I did was:
1) You should ALWAYS make back ups. (the 3 rules of computing are 1) Backup...2) Backup... and 3) you guessed it BACK-UP!!)
2) I opened a copy of the corrupt dB by holding down the shift key.
3) If you can open the IDE and see the VBA form module code, copy the code from each form and paste it into a text file (one text file for one form). Save the text file with the name of the form.
4) Provided you can open the forms in design view, open EACH form (one at a time), open the properties dialog box, click on the "Other" tab and set the property "Has Module" to NO. Close and save the form. This will delete the VBA project from that form.
5) Once all of the form modules are gone, if you can open the standard modules, open then (in design mode), copy all of the code and paste the code into a text file. I named the text file the same as the module name. Then delete the code module.
6) Once all of the modules have been deleted, create a NEW dB and copy the tables, queries, forms ( be careful to NOT copy a corrupt form, do a "Compact and Repair" after each object import) and reports. Do not copy the modules or you will have a corrupt VBA project again.
7) Again, do a "Compact and Repair" on the NEW dB.
8) Now the tedious part. If you were able to copy the VBA from the corrupt dB (if not, copy the code from a backup dB) and paste it back into each form.
a) Open EACH form (one at a time), open the properties dialog box, click on the "Other" tab and set the property "Has Module" to YES. Then open the text file for that form, copy the code and paste it into the form module.
9) Create NEW modules, rename them to the correct names, copy the code from the text files and paste into the modules.

Now, in the IDE, do a "Compile", then save the IDE (use the diskette icon or CTL-S).
In Access , do a "Compact and Repair". Close the dB, then open it. Open the "Main Menu" or whatever you call the first form that opens.

Hopefully, you have a working dB now.

thanks for that, yeah I had the first rule down pat of backup, but the 2nd and 3rd backup not so much, lol so that has changed for sure.

I was not able to open any form or access the vba behind most of the forms.

I think I know where the corruption happened and have gone about it differently, one thing i did copy and paste a couple of forms over (ones that were working before the corruption) they gave me some of the same error read outs when pasting them in the database but once in the db they have been fine and working as were before (I believe the error read outs were just continuing from the last db and once in the new db are gone).

I did backup the database before coping and pasting the forms, if this is a big NO NO to do please do tell.