In my department, about half of my co-workers and myself have Access 2007. The other half of the department has Access 2003. In the past month, the 2003 users have had the front end of a database come up as corrupt on two separate occassions. The 2007 users have not had any problem at all. Does anyone know why a database would become corrupt two times in one month? Could we be having a problem because some users are still in 2003? Is there a way to prevent the database from becoming corrupt? This is a huge database and is very important for tracking orders. There are seventeen tables, fourteen forms, about 100 queries, and about the same number of reports. Could the problem with the database be it's size? The main reason for the size is because within my department there are three different groups that each look at the order in a different perspective. The database follows the order from when sales enters it, to when the order gets processed by our ordering system, to when legal reviews it and makes sure all is correct in the system. Any advice you can offer would be greatly appreciated.
Question Continually Getting a Corrupt File
- Thread starter LadyDi
- Start date
And you say its the FE that comes up corrupt - not the data from the backend?
Your FE has forms and reports and queries - on each users mc
Your BE has Tables and queries
File limit on access is 2G if your wondering if your db is too large
Your FE has forms and reports and queries - on each users mc
Your BE has Tables and queries
File limit on access is 2G if your wondering if your db is too large
Thats whats got me.....
I'm using 2007 and I've had the same thing going on for the past 1 1/2 years in my front-end database, but only when I am developing. It seems to happen when I am making a lot of changes within a report or form.
The error message seems to stem around a gosub which I can never find. If I delete the form or report that I was working on and then compact and repair AND go back to a backup version and take the object prior to having the errors, I can get by the problem.
Needless to say, I must back up my work about 8 to 10 times a day so I won't get burned.
I am totally frustrated with this issue. I never had it when I worked in 2003, just 2007. Sorry to throw a curve.
I almost forgot - I had to remove the compact upon closing the database because that really had problems, but I may or may not have had a fix for that from Microsoft...just don't remember right now.
The error message seems to stem around a gosub which I can never find. If I delete the form or report that I was working on and then compact and repair AND go back to a backup version and take the object prior to having the errors, I can get by the problem.
Needless to say, I must back up my work about 8 to 10 times a day so I won't get burned.
I am totally frustrated with this issue. I never had it when I worked in 2003, just 2007. Sorry to throw a curve.
I almost forgot - I had to remove the compact upon closing the database because that really had problems, but I may or may not have had a fix for that from Microsoft...just don't remember right now.
- Local time
- Tomorrow, 01:53
- Joined
- Jan 20, 2009
- Messages
- 12,832
Are any temporary tables written to within the front end?
If so move them out to another local database and link them.
Writing to the front end is a very common bad practice that can lead to corruption. A static front end should not be corruptible.
Don't allow any saving in the front end at all. Include SaveNo in the form closing procedues to prevent changes in column widths and filters being offered for saving. (Disable the Window Close button and make your own Close button on the forms.)
However it does seem odd that all 2003 users copped it at the same time.
Are there any procedures that involve different actions depending on the Access version?
If so move them out to another local database and link them.
Writing to the front end is a very common bad practice that can lead to corruption. A static front end should not be corruptible.
Don't allow any saving in the front end at all. Include SaveNo in the form closing procedues to prevent changes in column widths and filters being offered for saving. (Disable the Window Close button and make your own Close button on the forms.)
However it does seem odd that all 2003 users copped it at the same time.
Are there any procedures that involve different actions depending on the Access version?
- Local time
- Today, 14:53
- Joined
- Sep 12, 2006
- Messages
- 16,072
lady di
can you clarify your system architecture - is the back end on a local server to all the users? are any users using wireless connections?
if all the users are getting corruptions, then maybe this is linked to corruption of the backend
can you clarify your system architecture - is the back end on a local server to all the users? are any users using wireless connections?
if all the users are getting corruptions, then maybe this is linked to corruption of the backend
All users have a copy of the front end on their hard drives. The back end is housed on a local network drive. As far as I know, all users are connected to the network with a cable. Sometimes, the users with laptops undock the laptop and use the wireless, but I think the majority of the time, they use the cables.
The first time the problem occurred, it happened on one person's computer one day. Then the next day, everyone else who had 2003 was having the same problem. The second time it happened, it only happened on one person's computer (of course, that was yesterday, so I am waiting for the bottom to drop out today). Both times, the front end will not open because, for some reason, it is trying to open a report or form (neither one of which is set to load on the on Open event of the database). When I made a copy of the form or report and then deleted the original, the database worked fine for all users.
The first time the problem occurred, it happened on one person's computer one day. Then the next day, everyone else who had 2003 was having the same problem. The second time it happened, it only happened on one person's computer (of course, that was yesterday, so I am waiting for the bottom to drop out today). Both times, the front end will not open because, for some reason, it is trying to open a report or form (neither one of which is set to load on the on Open event of the database). When I made a copy of the form or report and then deleted the original, the database worked fine for all users.
Galaxiom - you mention temporary files in the front-end... I use them a lot as I did in my 2003 version software without a problem.
I have this problem only when I am modifying code, forms, and/or reports. My users haven't had any problems at all...
Do you think that the temporary tables could cause a problem when I am coding?
I have this problem only when I am modifying code, forms, and/or reports. My users haven't had any problems at all...
Do you think that the temporary tables could cause a problem when I am coding?
Guus2005
AWF VIP
- Local time
- Today, 15:53
- Joined
- Jun 26, 2007
- Messages
- 2,636
I assume that the FE is copied to the users local directory before executing? This way each time you start with a fresh FE.
When did you last compact and repair de BE? Is a db1.mdb file created im the proces?
It sometimes helps when you export all objects from a FE to a fresh/new/empty database.
You might consider using SQL Server/MSDE as a backend.
HTH
When did you last compact and repair de BE? Is a db1.mdb file created im the proces?
It sometimes helps when you export all objects from a FE to a fresh/new/empty database.
You might consider using SQL Server/MSDE as a backend.
HTH
- Local time
- Tomorrow, 01:53
- Joined
- Jan 20, 2009
- Messages
- 12,832
A database front end is an application files. As a matter of principle, applications should not write to themselves. This separation of application and data is a fundamental premise of programming as old as programming itself. The principle of separation of the front end and Back End is emphasised to new developers by every experienced Access programmer.
You won't see an executable writing user settings to itself or using itself as a scratch pad. They use ini files and temporary files. I use what I have termed a database "Side End" as the equivalent for an Access application.
We have discussed this principle before in these threads:
http://www.access-programmers.co.uk/forums/showthread.php?p=922831#post922831
http://www.access-programmers.co.uk/forums/showthread.php?p=900437
This kind of writing to the FE is probably not the cause of your problem but solving issues in databases is often about eliminating all possible causes until one proves effective.
You say the problem happens when you try to save design changes to your developer version. Is this located on a network share? Perhaps you have a network issue.
All users have a copy of the front end on their hard drive. I compact and repair the back end of the database every Friday and I make a back up copy of the bank end each Friday.
All tables, with the exception of the two necessary to auto update the front ends, are housed in the back end of the database and linked to the front end. The corrupt files do not seem to have any connection to when I make programming changes to the front end. The problem occurs sporatically, and usually, what the error messages come up with are not parts of the database that I have made changes to.
All tables, with the exception of the two necessary to auto update the front ends, are housed in the back end of the database and linked to the front end. The corrupt files do not seem to have any connection to when I make programming changes to the front end. The problem occurs sporatically, and usually, what the error messages come up with are not parts of the database that I have made changes to.
I don't remember the exact wording, but it would say something like "Could not open Order Error Report" and it would ask if you wanted to fix it. Then there were Yes, No, and Cancel buttons. If you clicked Yes, it took you to the VBA code, and no where in that VBA code was the "Order Error Report" mentioned. Then when you close the VBA code and told it to stop the Debugger, it told you there was a corrupt file. If you clicked No, the message just kept re-appearing. If you clicked Cancel, it closed the database altogether.
Once I copied the object that it mentioned in the message and then deleted the original, everything worked fine.
Once I copied the object that it mentioned in the message and then deleted the original, everything worked fine.
Similar threads
