Hi guys i will appretiate it any hlp you can give.
A few weeks ago i started to experiencing problems with my access2k db. Some times i could open it and sometimes an error like this one.
"Microsoft Access has encountered a problem and needs to close. We are sorry for the inconvenience.
It asks to send a report and to repair the db
more data:
1- my jet engine version is 4.0.9025.0
2- because i eliminated the cross from everyform in the db sometimes i had to close access from the task manager.
3- i have never compacted the database.
4- it is still in development phase, so there are only a few records.
5- In order to use the db i have to use a citrix session in the usa (i am in australia), and from the citrix server connect to another drive in the usa. I also moved the db in the citrix server but i had the same problem.
Question:
if i copy the forms into a new db, will i have the same problem?
I inherited this user written multi user (<=10 simultaneous users) Access 2000 database. The front end in Access 2000, the back end is SQL 2000. All the tables are linked to SQL. When the users were running the Access front end on a Novell server there were no problems. We have sinced moved it to a Windows 2000 server and are now getting a Database needs to be repaired message 2 or 3 times a day. I searched the web and the only thing I came up with is that the Opportunistic Locks Setting on the Windows 2000 server needs to be disabled. Naturally our server team is reluctant to change the settings. Has anyone else experienced this problem or have any suggestions? Right now our solution ws to put a copy og the Access frontend on each user's C:, very ugly and difficult to maintain! Thanks so much for your help!
Hi, With my database I have actually distributed the mdb file to 2 of my users so that they can make their own reports. I have secured it so that these users cannot delete/modify anything they shouldn't.
However every so often it seems to get corrupt. I did decompile it and I tried importing everything into a new DB and secured it again. It seems to be working again but I wasn't able to find what was corrupt so I'm not completely confident that its fixed.
Would it be better if I gave them the MDE file - would it lessen the chances of it becoming corrupt??
When I leave the job I guess I will need to show someone how to decompile it in case there is a problem?
Viewing an email from Code Project, I ran across this article about database corruption and thought it was worth posting here... Be sure and click on the immediate link below to view the latest updates in the discussion area at the bottom of the web page. ---------------------- http://www.codeproject.com/useritems/rdb.asp
Strange behaviors of an access database By Hamed Mosavi.
Introduction
A while ago I encountered a strange behavior in my application which was using an access database (.mdb file). I placed a question in the CodeProject C++ forum, and I did not get any answer. I started searching the web, MSDN, etc... and I found out that it's not all my fault. I found the reason in a knowledge base article. Look at it's description about the possibility of corruption of an access database file:
"There are several things that can happen, both inside and outside of Access, that may leave your database file damaged (corrupted). The symptoms of a corrupted database can range from #Deleted appearing in certain records, to you being unable to open one of the objects in the database, to you being unable to open the database file in Access altogether." (MSDN-Knowledgebase:283849)
Since I got no answer for my question in the forum, I thought there are at least some guys out there who might don't know this , and also since it's easy to corrupt a mdb file, while it's difficult to understand the reason why the application is not Functioning properly, I started writing this article.
The question is what might cause a damaged access mdb file and also how to repair a damaged access file programmatically.
Background
What can cause the mdb file to corrupt The knowledge base says:
"There are three main reasons why an .mdb file may become corrupted, as follows:
* Interrupted write operation * Faulty networking hardware * Opening and saving the .mdb file in another program"(MSDN-Knowledgebase:283849)
There's a detailed description for each one of these in the knowledge base, but some of important reasons are as follows:
* Losing power during database write * Dropping network connection * Abnormal termination of microsoft Jet connection, such as having task manager to shutdown application, power loss, manual shutdown. (notice that:Fatal system errors almost always cause abnormal termination, refer to kb to find out more information) * Forgetting to close ADO or DAO objects that opened. (Objects from classes like:Recordset, QueryDef, TableDef, and Database) * A large number of open and close operations in a loop (more than 40,000 successive open and close operations could cause corruption) * And worst of all, Opening and saving the .mdb file in another program like MS word. It is not recoverable. all your data will be lost.
"There is no way to recover an .mdb file that was opened and then saved in a different program" (MSDN-Knowledgebase:283849)
How to reduce corruption possibility
* Avoid all above * Compact the database often (The class provided with this article)
Things can get worst Q291162: AutoNumber field duplicates previous values after you compact and repair a database: Microsoft also announces that after we compact and repair our database, it is possible to encounter Duplicate Autonumber field, and if it's your database key, then... fortunately this applies just to those who are using Microsoft Jet version 4.0.2927.4 and earlier. "Microsoft has confirmed this to be a problem in Microsoft Jet version 4.0.2927.4 and earlier." (MS KB Q291162). to find out your Jet engine version try to search your system/32 directory for Msjet40.dll (if you are using v.4 and later) then get the properties of the file. This KB can help you find your version and download latest version:Q239114
Another bug exists there and it's "AutoNumber field is not reset after you compact an Access database" I don't describe a solution for this, since there is one already, and it is not really critical, for more information refer to KnowledgeBase Q287756.
if you lost data and have problem recovering data(yet), this can help you a lot: Q247771 and Q306204.
Using the code
In order to use the code, follow the following steps:
1- Copy DBFitter.cpp and DBFitter.h to your project. 2- Check and possibly change first two #import directives in DBFitter.cpp.
3- include DBFitter.h, Create an object from type DBFitter and use it as follows:
CDBFitter fitter; if ( !fitter.CompactAndRepair(szDbPath,m_szDBPass) ) { AfxMessageBox(fitter.GetLastErrString()); }
CompactAndRepair has 3 forms that can be used alternatively. The first one you see above , The other form just gets database file path as input and does not use password
CompactAndRepair(CString szDbPath)
The last one asks for a source, a destination and password, which can be given "" as password to say there is not a password
4- Don't forget to call AfxOleInit(); in the initialization of your application.
"What to Make Sure of Before You Run the Compact and Repair Utility Before you run the Compact and Repair utility on a database, make sure of the following:
* Make sure that you have enough free storage space on your hard disk for both the original and the compacted versions of the Access database. This means that you must have enough free storage space for at least twice the size of your Access database on that drive. If you need to free some space, delete any unneeded files from that drive, or, if possible, move the Access database to a drive that has more free space.
* Make sure that you have both Open/Run and Open Exclusive permissions for the Access database. If you own the database, make sure to set these permissions. If you do not own the database, contact its owner to find out if you can get these permissions.
* Make sure that no user has the Access database open.
* Make sure that the Access database is not located on a read-only network share or has its file attribute set to Read-only. " (Q283849)
Compact and repair in C# Thanks god, there is already an article: http://www.codeproject.com/cs/database/mdbcompact_latebind.asp
--------------------------
If there are any questions or feedback; please direct them to the original authors link at the top of the page so everyone can benefit.
I have a small database being used concurrently by 5-6 users, in the last few weeks we have had some corruption issues, the users are running a mix of access 2000 & 2003 – would unifying versions help these corruption issues?
Also what is the recommended maximum number of simultaneous users accessing one a DB in a LAN/WAN environment?
I believe I have discovered a new way of fixing corrupted forms in Access.
After a crash, one of my forms refused to open in either design or form view saying: Form name | is misspelled or refers to a form that doesn't exist
Having searched the internet for this error I found lots of people recommending Repair/Compact or copying and pasting the currupt object into a new database.
Repair and Compact (Access 97) both ran successfully but failed to fix the problem.
When I attempted to copy and paste the broken form either within the database or externally I got
Error 13: Out of Memory
When I attempted to import the form into a new database I got
Automation error
If I attempted to rename the form, I got:
The save operation failed
Resolution: (I don't know which step here was the key to my success) 1) Delete all other database objects (all tables, queries, forms, macros and modules) 2) Create a new form and put any control on it. 3) Attempt to save the form using the same name as the corrupt form 4) Access asks "The name you entered already exists..." (Aha! The first time Access is admitting that the corrupt form exists.) Say no to this prompt. 5) I was now able to rename and open my corrupt form. Everything was fine.
If this post stops just one other DBA having to go through the morning from hell I just went through then it'll all have been worthwhile!
I have been searching for an answer to this, but no luck. Has anyone ever seen the below error when loading an Access 2003 database?
"[database name] has detected corruption in this file. To try to repair the corruption, first make a backup copy of the file. Then, on the Tools menu, point to Database Utilities, and click Compact and Repair Database. If you are currently trying to repair the corruption then you will need to recreate this file or restore it fom a previous back up."
The database is already compiled and compacted. It's a new Access 2003 program. Only one user is experiencing this problem. She is on XP while the others are on Windows 2000. Everyone is using 2003. I saw other odd error messages on this machine with other databases, but I was able to avoid them by setting the Macro settings to Low. This is a Network environment. Any thoughts?
i'm getting annoyed by Access 2003 (and 97 for that matter!) just corrupting records in a table and then i have to scrabble around, kicking people out the database, compact & repairing, maybe installing the back up copy and in one case, doing a make table query from the data table that excluded the corrupted record
:(
are there any general things i can do to avoid these things, or am i just going to have to roll with them?
I have a split database. BE located at a server and FE on each users workstation. There are 8 concurrent users at the most. This runs smoothly over the LAN.
Now I'm adding a new feature to the database. I'm using a wheel loader to weigh products on a weight scale. The operator in the wheel loader is going to use a laptop with wireless LAN to connect to the network.
In risk of loosing the connection which in worst case might corrupt the database, I want to make a new database with a BE/FE setup. The BE will be placed on the same server as the current db. The FE in the wheel loader. I can then link from the current db (BE) to the new db (BE).The new db will only require two linked tables from the current db.
If worst case happens, would my current db be more protected against corruption than if I linked directly to the BE on the current db. I know there's no 'right answer' to this one, but I'd really like some opinions on it though.
Hi all, apologies for the long post but this is a long nightmare!
Using A2k on Win2k...Due to roll out a DB today, just made my final tweaks and decided to compact/backup as have done many times before. It's not a split DB but it is secure so I copied the mdw onto my desktop and accessed it using a special compact shortcut which points to the desktop copy DB not the one on the network. When I compacted though Access went about it's business for a while and then threw up the dreaded "Network connection may be Lost" error message (roughly translates as "your database is nicely corrupt now") which I have had in the past when I tried to compact on the network. I've never had this error before compacting locally but anyway I tried again and same error message. I tried opening some forms and stuff and sure enought the DB was corrupt. No probs I thought, I can just go back to the original and start the process again. I used the normal shorcut to open the original DB just to check everything was ok and the same error message appeared with same problems. Minor panic ensued and I thought i'd got the shortcuts mixed up or something... I hadn't, Both DB's were affected.
Next option. Create a new DB and import all the objects. I did that and re-set all the permissions and the "Network Connection Lost" message dissapeared but some really strange things were happening. Forms opened but the buttons on them would do nothing. Then the forms Close button didn't work and the database wouldn't close.
I forced my way out of the DB and re-started my machine. Couldn't even log in to windows. Now at another machine and can log in to windows but DB is still having same problems. My instict tells me that the problem is something to do with the workgroup file becuase how else could compacting a copy corrupt the original? The only common link is the mdw.
Should I re-create the mdw and then try opening/importing the DB objects again? Or is there any way I can un-secure the DB and then re-secure it later?
In my access 2003 application, I can open the database and goto the design view of the Forms..but I cannot view the code. I tried both Alt+F11 and Right click on the form and "Build Even" and "Code Builder".
In both cases, access application stops responding. Then I have to close it using the task manager.
Any ideas how to fix this issue? Thanks in advance for your help. :confused:
I have been experiencing some very strange symptoms over the past week or so, and am looking for ideas. I have a number of different frontends that link to one or more shared backends. A week or so ago, all the frontends were reporting that one of the backends, PCAMaster_be, was corrupt (ie, "not a recognizable database format). I repaired it, it worked ok, and then a few hours later it was corrupted again. After going through this a few times, I rebuilt the be (imported everything into a new, blank db). Same thing -- it was OK for awhile, then became re-corrupted.
So, my conclusion was that: a) one of my frontends was corrupting it,or b) my shared library.mde file was the culprit, or c) my shared .mdw file was the culprit.
I have been meaning to unsecure my db's for awhile becuase I don't really use the security in any meaningful way. So, spent most of the day yesterday going through the steps to unsecure. So, I'm not using anything but the default .mdw file now. I also rebuilt every single FE, BE, and the library.mde.
Now, PCAMaster hasn't gone corrupt again (yet), but I'm noticing several other bothersome symptoms:
1. In one of my FE's, when I close it, the application closes but it leaves Access running. I have to use task manager to get access to close.
2. Some of my .ldb files seem to stick around when they're not supposed to. I am 100% certain that NO ONE is using the db. But the .ldb file is still there and I can't make it go away.
3. I open a FE with the /excl command line option. It opens OK, but when I try to repair/compact, it won't let me. ANd if I try to make design changes, it says I don't have exclusive access.
Heyo, thought I'd toss my line to see if anyone has had a corruption like this:
Today I went digging through some of my tables on a db I've been building and noted that most (but not all) of my text fields had Unicode Compression/Off and Zero-Length-Strings/Allowed. Now, I know for certain that I never touch Unicode Compression and zero-length strings are not my bag in this db so I went to toggle these and I recieved 'Access encountered an error when attempting to save' type error when I, you guessed it, attempted to save.
So I built fresh tables, and imported my data, and all seemed well but digging further through my database I have noted that ALL of my tables seem to be suffering from this in some way.
First off, does anyone know what has happened? Secondly, does anyone have a guess as to why this happened? Lastly does anyone have a suggestion on how to rectify this?
I'm not a huge fan of building this entire gigantic db from the ground up and I'll do it if I need to, but I'd prefer to figure out what went wrong before we get there and it happens again.
I'm running Access 2000 through Citrix, 20 users internationally from 1 db. I'm working through Citrix network issues to split db with separate FE's for each user. I have sporadic corruption due to this. But this morning I met a new breed of corruption. I preface this with the fact that I run a bat file nightly to do clean up and compact and repair the db. It verifies the db is not in use prior to running. This morning we were presented with a hosed db. The log file said updates ran fine. In my main table the first record was garbage, including the Auto-num field. I found that my Primary key has lost it's index and references had become unchecked. Correcting these issues got it running but does anyone have any clue what might have triggered this or even where I should start looking? Please help as I am at a loss. Thanks.
Hi, I've searched through the archives and cant seem to find an answer to my problem - hopefully someone may be able to shed some light on this for me as it is driving me mad!
One table in my database keeps getting corrupt records; I get various error messages when navigating a particular form - including 'Record is deleted' (when it hasnt been), 'The search key was not found in any record, 'Object invalid and no longer set' etc. After receiving one of these messages one or more records in my table corrupts (strange symbols and #Error# appears in the fields) - I have to compact and repair and delete the record.
I have imported everything into a new clean database several times but the same thing keeps happening.
Additionally the table that keeps corrupting is randomly 'losing' its primary key and relationships - they just simply dont exist anymore. I understand that importing into a new database could cause this - but they arent disappearing after I have imported; the database can be running fine and then after a few days I check the table again and the primary key is no longer set and the relationships to other tables have disappeared.
I am compacting and repairing every day and having to recreate a new clean database about once a week - and keep getting the same problems with the same table!!!
Has anyone seen this happen before and could anyone suggest where I would begin trying to resolve this. Any advice would be REALLY appreciated.
One table with an autonumber field becomes corrupt after each Compaction and Repair.
When I add a new record to the table the new autonumber is an already existing autonumber, hence, I get a duplicate value error.
I fix the corrupt table by importing it to a new database. (Access seems to recreate indexes / autonumber fields during an import). This always fixes the autonumber problem. I then import the properly working table back into my original database.
However, next time I Compact and Repair the same table becomes corrupt on the autonumber field.
Some of my collegues have been experiencing this problem with a very simple database i knocked up for them. First off some background. I have a main form (frmproperty) with 3 subforms linked to it(frmroomdata, frmlocation and frmsample). by a property code. Two of these subforms are linked (frmlocation and frmsample) these are linked by location code which is an autonumber.
These are laid out so that you fill in room data first, then location data then finally sample data. However after the location data has been filled out and a user attempts to move to the first combobox on the sample subform a message pops up saying that another user has altered the database and would you like to save changes (Impossible as they are using the database on a local drive). After this happens they reopen the form and in all the frmsample fields is "#deleted"
This doesn't happen every time...infact over the last 2 days i have been entering data myself to try and get this error with no luck. Has anyone else come across this and know how to fix it?
Ok, here's the deal. I'm tired of fixing our gigantic table because of corrupt records in my firm's database. I find that the problem ordinarily comes up when someone opens the same record in two different forms (whether on the same computer or on a different machine) and both attempt to make changes. Is there a way (preferably simple) to just LOCK a record in a particular table to keep this from happening? I assume there has to be, but I've just never taken the time to find out. I'm not sure if this locking is done on the form level or somewhere in a table option or something.
I link to an excel spreadsheet. all the data is except where Ive had to format a "column" of cells as text. This is done because in the spreadsheet the initial user enters data as text, numeric or a mixture of both (hope thats clear).
My problem is the data that was originally numeric and now formatted to text comes out at #num! ( Yes ive posted similar before) However, when ive imported the same data in to a pre-made table to try a different way of achieving the final job the numeric data (now formated to text) comes out like ---- e.g. instad of 1000344 it comes out 100034+007
And now Ive absolutly NO idea what to try next. Its one Ive never seen before. If i go in to either the linked spreadsheet or the premade table and over type the errors with the correct data - no problem! So it seems like a conversion issue
I'm in the process of rolling out a new database that will require some data entry from approximately 35 users.
I have been told that database corruption WILL (not might) occur if more than one user is in the database at a time, which I find hard to believe. I was told that if multiple users who have different permissions levels are in the DB at the same time, this will cause corruption.
Has anyone heard anything like this?
Also, there will only be one or two forms that my users will be using for data entry. The rest is report running. If I set the value Record Locks on the form to EDITED RECORD, will this prevent corruption?
Any input you could provide is very much appreciated. I haven't been able to find any info specific to this issue.
I hope this hasn't been addressed too many times before, I searched for 'corruption' but there were so many results that I could only parse the first few pages.
Anyway, I'm developing a C# app for personal use and I was planning on using some MS Access functionality, namely saving and loading data from MDB files. Unfortunately, I've heard a lot of scary stuff regarding Access's tendency to corrupt MDB files. This is really bad news, as I really can't afford to lose any data - information is fed into the application daily, even hourly, and the data isn't stored anywhere else.
I could - and will - add some code to back up MDB files on every access, but I'm still curious. Given the circumstances listed below, how likely is Access to corrupt a MDB from time to time ?
- I am the sole user of the database. It is never, ever, accessed by more than one user at the same time. There is no networking involved whatsoever. - The database contains only tables and maybe some forms. There are no constraints, stored queries, or any advanced features like that. The forms are never actually used by the program, they're just there to help in editing the database 'manually' should the need arise. - The tables contain only basic data, i.e. INTs, VARCHARs and DATETIMEs. No memos, images or any such stuff. - The database engine / system will not crash in the middle of a writing operation, or if it does, there will be a certified backup available. - There are only two possible operations that the program can perform on the database: either a bulk read on each table, or a complete replacement of all of the records in all tables. There are no selective insertions or deletions.
What I want to avoid most is a 'silent' corruption, i.e. Access reports having saved the table successfully, but it has actually corrupted some records. It's not a problem to keep a backup for the duration of a writing operation (to cover the case in which the engine crashes during writing), but if I need to keep it for anything longer than that, the situation becomes rather cumbersome.
I added a new field to a table, and saved the table. When the table is reopened, the new field is not there! I thought perhaps I forgot to save the field, so I tried adding the field again. When saving, the error said, "cannot save; duplicate field name".
If I go to toolsoptions and click the "show system objects" the field will show up??
Do you think the best course of action is to import all the objects into a new db and try again?
This error message appears when trying to open an Access XP database:
"Microsoft Access has detected corruption in this file. To try to repair the corruption first make a backup copy of the file. Then, on the Tools menu, point to Database Utilities and click Compact and Repair Database..."
But when you try to do what it suggests, it does not work. Even if you hold down the shift key when opening it, the message appears. Anybody have any ideas?
In our company we use a windows 2003 server. Our database is ms access 2002. The back end of the db is situated in a directory on the primary HD of the server. All our workstations use windows professional. The DB works great when inputting data from workstations using widows pro.
I use a vista (ultimate) laptop. It appears that when I enter data from my vista laptop at times it corrupts the backend of the db. None of the other workstations do this. Is vista a problem here in this situation?
:eek: I have a large table with 1 damn corrupted record, the database can't be repaird, compact, I can't use the copy ,method since the table is over 9000 record sets.
I tried creating a new table and appending the non-corrupted record into it with no success, it is keep locking on me.
Have you guys tried anything else that works for this situation???
