Access - Corrupt External File

Thank you Ste5an

Oh my gosh - I am trying to explain this to people - and unless you know what this entails - it is not understood.

So - I take it that once you have had a corrupt db - that you had to restart a lot.

Also - I have asked others - but does not hurt to ask again - they indicated yes - but if I have a corrupt db - it could have been corrupt for a while before shutting down - and this would have affected queries, calculations, etc - long before it became inoperable.

In other words - if there was a corruption issue flowing through this - I cannot 100% trust any of the data/reports that were generated. Please confirm.

Thank you.

What exactly is a "corrupt external file" in regard to Access?

As ste5an mentions the most common cause of corruption is network-related - i.e. a dropped connection. If you're using Access across a WAN or wireless network, then you're much more likely to have troubles.

But without knowing what a "corrupt external file" is, we can't really comment further.

Thank you both.

By the way - I realize that I am on wireless a lot when I work on db.

Also, now that I look back, Access must have been giving me signs that it was not good - but I ignored to just regular mishaps.

What are some of the common signs that I should expect to indicate that the db is heading in a downward direction.

Thank you.

Well, I guess it's time to ask these:

Do you use a split architecture? Thus do you have a local front-end file and one or more remote back-end files?

Using a split architecture means: Create one database (.accdb) to store the "front-end" objects like queries, forms, reports and modules. And use the back-end database to store only the tables.

Then you can use Compact on Close on the front-end, which tells you when your UI goes corrupt. And making backups of your back-end database is also better, cause the database file is now much smaller.

By the way - I realize that I am on wireless a lot when I work on db.

Access does not work on a wireless network. It might work for a while, but you will inevitably corrupt the database (and it happens quite often).

What are some of the common signs that I should expect to indicate that the db is heading in a downward direction.

There's really not much warning, but there are quite a few symptoms that will let you know when corruption has occurred. Tony Toews has a good compilation here:

http://www.granite.ab.ca/access/corruption/symptoms.htm

But your focus should be on PREVENTING corruption, not recognizing it. I have a LOT of Access customers who never experience corruption, simply because (a) their application is properly designed, (b) their application is running on a solid infrastructure and (c) they've been trained in the correct way to use the system. If ANY of those 3 fail - and at the very least, you're failing on (b) - then you will almost certainly experience corruption, and sooner rather than later.

By the way, I'm not a big fan of Compact on Close. In a split architecture, it only compacts the Front End, and that's typically not a big issue to repair (you just deploy a new FE to the machine). It's the BackEnd (the part storing the data) that you need to be concerned with, and ConC has no impact on that.

Thank you so much for taking this time. I do create many access db for projects I am on - and am now leaning that it may that I am on wireless most the time. I have too much work invested - so do need to focus on preventing this.

Thanks so much.