Database.mdb, Database1.mdb etc.

[Thirith]

The project database I created for work has been generating smallish files named Database.mdb, Database1.mdb, Database2.mdb etc. After 2+ years, we're at Database61.mdb. All of these files are under 1MB, some being no larger than 180KB.

Can someone explain to me what those files are and whether they're supposed to be generated? Are they required for the ongoing functioning of the database? I've just noticed that this afternoon, two of these files were generated, and we've had problems with the DB becoming corrupted - do they come about when the DB is corrupted and needs to be repaired? If so, can I safely delete all of them if the DB is working correctly?

 

[Micron]

That is not normal behaviour and implies that either you have code that creates numbered backups (not likely) or that Access is creating them because it either doesn't start or close properly due to some problem, which is likely corruption. If your data all looks OK to you it's likely that you could safely delete most of them (all of them if you are doing your own backups, which you should be). What isn't clear here is if Access is failing and you don't notice, or you're aware when it happens. The issue won't be Access itself; rather the db will more than likely be the issue.

I'd first create a backup copy that you'll be able to easily id, then open that and do a compact/repair then test. If that doesn't help, you could try a decompile on the copy (open db with the compile switch). In the meantime, try to observe when copies are created and watch for abnormal things when opening/closing your db. F'rintstance, when you do something with a form record, there might be odd behaviour taking place.

If those tactics fail, you could open a new db and import everything into it, hoping that the corruption is taken care of (if that's what the issue is). However, it is possible to bring over a corrupted form or report and the problem continues. If you manage to id the problem object, you could try recreating it from scratch.

 

[jackd]

I agree totally with micron's assessment. This is not normal. However, I have had situations where something I was doing has gone wrong and Access "detected" some condition and offered to save a copy of the database with a new name (if I recall it was suffixed 01 or similar). When this happened, I was aware and could compact and repair and carry on. But to have ~60 of these on your system and not knowing they were being created indicates an issue to be resolved.

How critical is this application to your "business"? You or someone should be monitoring your disk usage especially if there are ~60 mdb files with "similar names".

You may want to post a copy of the database for readers to review.

 

[petertenthije]

is it possible that the database is used by multiple people simultaneously? If you have the database set up to automatically do a “compact & repair“ on closing, then that might lead to copies.

 

[Thirith]

@petertenthije The database is definitely used by multiple people simultaneously, though each has their individual frontend. The DB is also set up to automatically compact & repair on closing - is the recommendation that this isn't done when you have multiple users at the same time?

@jackd The database is fairly critical for our work. It's where we store all relevant project information and how we manage our workflow. I don't know what kind of disk usage monitoring we've got set up in our organisation, mind you; I expect we have *something* set up, but this may be based on space rather than on the number of files, and all in all those Database.mdb files wouldn't amount to more than a few MBs. Since the database consists largely of confidential and organisational information (we're a national research funder), I'd have to strip out so much information that I'm not sure what would be left.

@Micron Those Database.mdb files are considerably smaller than the data set itself. As far as I can tell, the data in the database is okay, and it works fine - though every now and then it does end up corrupted and I then have to repair it. We've never found out how to resolve this issue, but it's happened across various databases across the organisation from time to time, most of which are made from scratch, i.e. not using a common template. (I wonder whether it's less an issue with the databases themselves and more with our network, since we've run into lots of issues with it over the years.)

 

[Micron]

AFAIK, you should never have to compact/repair the back end as long as you're not poking around in it manually, playing with table design and such. One thing not mentioned here is wifi and cloud. If you use Access over wifi in multi user corporate network setting or over the cloud in any setting you're asking for trouble.

 

[Thirith]

Thanks, that makes sense. Unfortunately we are asking for trouble, or rather, we've not had the choice not to over the last two years. Most of us have been working from home for at least half of that time, accessing the office network via some kind of remote access, and the kind of infrastructure people have been using varies considerably. I'm actually surprised that it's all worked as well as it has.

 

[Micron]

If you're using some sort of terminal service (e.g. Citrix) then you're likely using a server which contains the db, or directly accesses it over the network as if you were there. In those cases, what you're remotely using is a server, not the db itself.