Upgrade file from mdb (2000) to accdb???

[MrsSpalla]

I'm just about to do some major updating on my database. My current file is in a mdb 2000 format and I plan to update it to ACCDB. One of my biggest reasons for doing this is to keep our users from using the 2003 program. I also wanted to bring us up to a more current version for whatever the future holds.

Is conversion a good idea? Is there any reason (there than users and group permissions) to keep my file as an mdb?

Also, I'll be splitting my database into a front and back end. So should I convert both files to accdb? I've read in a couple places that accdb files are more susceptible to bloat - which is already a problem in our current database version.

Any suggestions or opinions?

 

[Galaxiom]

I would strongly advise avoiding accdb but upgrade to the 2003 mdb. Be aware that accdb is not a single specification. The 2010 version has features that are not compatible with 2007.

Importantly the 2007 accdb does not support digitally signed front ends, only signed installation packages so distribution on a secured network is quite clumsy compared to simply copying the signed frontend to the user's Application Data folder.

There are no features of any consequence in 2007 accdb compared to mdb. Like most experienced developers, I will never ever use multivalue fields.

I design in 2007 mdb but distribute mde files. Most of my users only have 2007 Runtime installed which happily runs mdb. Those with the full version are set up to run the file in Runtime mode with the switch.

 

[jdraw]

I agree totally with Galaxiom. There are a lot of happy 2003 users, and as far as bloat goes, do regular Compact and Repair.

 

[MrsSpalla]

Good information! Thanks to both of you. I'll do a 2003 mdb upgrade and leave it at that.

As far as bloat goes, I do a compact and repair about every other day when my database has quadroupled in size. Rather obnoxious!

My database was set up VERY poorly set up (like so many others I inherited it). It needs a major rehaul - like scrapping it and starting over. But I'm not there yet. Presently I needed to get it to a working state. It had many corruption issues, and you should just see my relationships table. OIH! I think this database breaks just about every rule.

I'm looking into a total redo around the end of the year.

 

[jdraw]

Usually bloat is caused by creating and deleting temporary tables, queries etc. or by storing images in the database. All these have some sort of work around.
Good luck with your project.

 

[Galaxiom]

The fact that it isn't split would be the prime candidate for corruption when you have multiple users. I would do this immediately.

I even split single user databases. It is a good idea to keep the program and data separate.

It is quite possible to have two different versions of the front end interact with the same data so it is a very smooth development path. Unsplit databases always face resynchronising the data if the old version is continued in use while the code is developed in the new version.