Unrecongized file data.mdb
Closed
salai_k1
Posts
10
Registration date
Tuesday September 1, 2009
Status
Member
Last seen
April 6, 2012
-
Apr 6, 2012 at 11:42 PM
Blocked Profile - Aug 28, 2012 at 04:21 AM
Blocked Profile - Aug 28, 2012 at 04:21 AM
Related:
- Unrecongized file data.mdb
- Windows 10 iso file download 64-bit - Download - Windows
- Kmspico zip file download - Download - Other
- Tiny 11 iso file download - Download - Windows
- Ms office save as pdf or xps file - Download - Other
- How to open .msi file - Guide
3 responses
You can't open your .mdb file due to corruption. Do you have a backup for .mdb file? If your answer is yes then you can easily restore your file from it. But if the answer is no, then you need to consider these points:
1. You can try to open your .mdb file in other MS Access programs which support .mdb file format.
2. You can import you data from corrupt .mdb file into a new database file. Try it.
3. You can use Compact and Repair database utility. It is free. Some cases it works very nicely, but when .mdb file is heavily damaged then it could be failed to repair.
For more you can read this article. It is very informative.
https://ideamarketers.com/?how_to_repair_access_database&articleid=3491283
1. You can try to open your .mdb file in other MS Access programs which support .mdb file format.
2. You can import you data from corrupt .mdb file into a new database file. Try it.
3. You can use Compact and Repair database utility. It is free. Some cases it works very nicely, but when .mdb file is heavily damaged then it could be failed to repair.
For more you can read this article. It is very informative.
https://ideamarketers.com/?how_to_repair_access_database&articleid=3491283
rizvisa1
Posts
4478
Registration date
Thursday January 28, 2010
Status
Contributor
Last seen
May 5, 2022
766
Apr 8, 2012 at 08:42 AM
Apr 8, 2012 at 08:42 AM
see if this help
https://support.microsoft.com/en-us/help/283849/
https://support.microsoft.com/en-us/help/283849/
arnoldanderio12
Posts
1
Registration date
Tuesday April 24, 2012
Status
Member
Last seen
April 24, 2012
Apr 24, 2012 at 12:15 AM
Apr 24, 2012 at 12:15 AM
Your database will corrupt during development when objects and code are constantly being designed and tested. These tips will reduce but not eliminate corruption:
Install the latest proven service packs for your version of Access and JET.
Turn off Name AutoCorrect before creating any objects in your database. This thing is buggy, incomplete, performance degrading, and contributes to corruption. Turn if off under File (the Office Button) | Options | Current Database (Access 2007 and later), or in older versions: Tools | Options | General.
In your subforms, include a text box for each field in its LinkChildFields property. This simple step avoids frequent of Access 2002 and 2003 ("... shut down by Windows..."), where the form is based on a query (not directly on a table.) The text boxes can be hidden if you do not wish to see the foreign key fields.
Never allow multiple developers to modify the objects in a single file at the same time. Give each one a local copy, and import their objects back to the main copy later. This tip alone will save you much grief.
Do not edit the text of a module while it is running (i.e. in break mode). If a project is compiled, and you edit the text while it is running, the Compile item on the Debug menu may remain greyed out. This may indicate that Access has become confused between the different copies it keeps of the code: the compiled code, the text-version of the code, the text-version of the temporary copy that it creates when you edit the form's module, and the version that is actually running. Refusing to edit code in break mode significantly reduces corruption in my experience.
Watch out for the first hint of corruption, and take action. A project is beginning to corrupt if the Compile doesn't hold. If a compiled project is uncompiled after a restart, it is time to backup, compact, decompile, compact again, compile, and make another backup copy.
If Access crashes, do not allow it to compact and reopen. Delete the ldb file. Create a copy of the crashed database. Then reopen, and compact/repair. If it did corrupt, it may be possible to rescue some objects from the corrupted database provided it has not been compacted. The undocumented commands SaveAsText and LoadFromText are useful in this context.
Create a backup copy and compact regularly during development. Our pattern is twice a day, so we never lose more than half a days work.
In your code, close everything you open and dereference your objects. If you do not open something (such as the default Workspace, or the RecordsetClone of a form), do not close it, as that can cause problems. If you do open something (such as OpenRecordset), close it. Then set all object variables (Form, Recordset, TextBox, ...) to Nothing.
Be especially careful with any code that does not have the normal safety net VBA provides, e.g. Eval(), API calls, late binding.
Use DoCmd.Echo True in the error recovery section of any procedure that turns Echo off. This will prevent you (and the end user) from crashing out of Access because it is visually unresponsive.
Split the database, and give users an executable version that cannot decompile:
In Access 2010: File | Save & Publish | Make ACCDE.
In Access 2007: Make ACCDE on the Database Tools ribbon.
Earlier versions: Tools | Database Utilities | Make MDE File
Unless you really need it, turn off Record-Level Locking (as opposed to Page-Level Locking.) Page-Level locking is more efficient to execute, and works more reliably in some circumstances. In Access 2000 - 2003, uncheck the box under Tools | Options | Advanced | Open Databases Using Record-Level Locking. In Access 2007 and later, go to File (Office Button) | Options | Advanced.
Install the latest proven service packs for your version of Access and JET.
Turn off Name AutoCorrect before creating any objects in your database. This thing is buggy, incomplete, performance degrading, and contributes to corruption. Turn if off under File (the Office Button) | Options | Current Database (Access 2007 and later), or in older versions: Tools | Options | General.
In your subforms, include a text box for each field in its LinkChildFields property. This simple step avoids frequent of Access 2002 and 2003 ("... shut down by Windows..."), where the form is based on a query (not directly on a table.) The text boxes can be hidden if you do not wish to see the foreign key fields.
Never allow multiple developers to modify the objects in a single file at the same time. Give each one a local copy, and import their objects back to the main copy later. This tip alone will save you much grief.
Do not edit the text of a module while it is running (i.e. in break mode). If a project is compiled, and you edit the text while it is running, the Compile item on the Debug menu may remain greyed out. This may indicate that Access has become confused between the different copies it keeps of the code: the compiled code, the text-version of the code, the text-version of the temporary copy that it creates when you edit the form's module, and the version that is actually running. Refusing to edit code in break mode significantly reduces corruption in my experience.
Watch out for the first hint of corruption, and take action. A project is beginning to corrupt if the Compile doesn't hold. If a compiled project is uncompiled after a restart, it is time to backup, compact, decompile, compact again, compile, and make another backup copy.
If Access crashes, do not allow it to compact and reopen. Delete the ldb file. Create a copy of the crashed database. Then reopen, and compact/repair. If it did corrupt, it may be possible to rescue some objects from the corrupted database provided it has not been compacted. The undocumented commands SaveAsText and LoadFromText are useful in this context.
Create a backup copy and compact regularly during development. Our pattern is twice a day, so we never lose more than half a days work.
In your code, close everything you open and dereference your objects. If you do not open something (such as the default Workspace, or the RecordsetClone of a form), do not close it, as that can cause problems. If you do open something (such as OpenRecordset), close it. Then set all object variables (Form, Recordset, TextBox, ...) to Nothing.
Be especially careful with any code that does not have the normal safety net VBA provides, e.g. Eval(), API calls, late binding.
Use DoCmd.Echo True in the error recovery section of any procedure that turns Echo off. This will prevent you (and the end user) from crashing out of Access because it is visually unresponsive.
Split the database, and give users an executable version that cannot decompile:
In Access 2010: File | Save & Publish | Make ACCDE.
In Access 2007: Make ACCDE on the Database Tools ribbon.
Earlier versions: Tools | Database Utilities | Make MDE File
Unless you really need it, turn off Record-Level Locking (as opposed to Page-Level Locking.) Page-Level locking is more efficient to execute, and works more reliably in some circumstances. In Access 2000 - 2003, uncheck the box under Tools | Options | Advanced | Open Databases Using Record-Level Locking. In Access 2007 and later, go to File (Office Button) | Options | Advanced.
