Within my company, there are 3 versions of Access: 97, 2000, and 2002-. I think the database I'm currently working on needs only to work for 2000 and 2002. Since my computer has 2002, am I able to use it to update a version 2000 database? If I use it as a 2000 db all the time, will Access 2002 only allow me to program 2000-compliant code? Even more important: what happens when you convert to a previous version that accept some of your code? I'm really curious as to what will happen if I have to convert back to 97, because it seems I can't alter the db while it's in 97, but I can in 2000. Is there a good resource out there for dealing with multiple versions?
There are currently 4 versions of Access in common use:
Access 2002 (also called Access XP)
Access 2003 (also called Office 11)
Access 97, while it will run the most common features in all versions of Access, is probably the version you should get away from as soon as possible.
There are several reasons to do this:
The file format is not supported by 2000-2003 unless you convert it back to 97. If you do this, you may run into trouble with other users who are linking to more recent versions of Access.
There are fewer developer components available to you so you have to work harder to achieve the same results when creating databases and programs.
The Visual Basic editor in 97 only allowed you to view each module, form or report, one at a time. You had to go to the window menu option to switch to another Visual Basic object. At the very least, this is extremely annoying to anyone who is used to just double-clicking to switch between modules and object classes in the Visual Basic explorer.
Access 97 contained almost none of the more recent HTML/based features that are becoming the norm in later Microsoft Office products.
Finally, Access 97 has too many bugs as it was an early version that used the Visual Basic programming language (and a great stride for the application at that time - but there are better versions of Access available).
I would probably try to use Access 2000, at the mimimum, as the lowest version of Access for your company.
I believe the time and money and reduction of headaches you will encounter by moving everyone out of 97 will be well worth the cost of the licensing.
I totally agree with you, but I have no sayso in pitching Access 97. I have multiple versions because the users are from different organizations- govt and its contractors. I think the upgrade idea has been sitting around since Access 2000 was new, so I'm not holding my breath.
I already ran into multiple-version problems as described in my other posting you responded to. The nested forms worked in Access 2002, but when I had to convert back to Access 2000, it didn't work anymore.
I understand. I have a couple of 97-2000 hybrid databases out there on servers. Here's what I would do:
I would keep the databases as plain vanilla as possible. Basically, you want to write the apps for 97 as much as possible. I would probably test in 97 and then convert to the later version, once the 97 app is working fully.
You have 3 options as far as version control.
One is to build the app in 97 and convert it to the new version prior to installation.
Two is to build it in the later version and save it back prior to rollout. Just the opposite of the first option. You have the advantage of working with a better VB editor but, as you pointed out, run the risk of a feature no longer working when you roll back.
Three is to build two versions. You determine where the troublesome features are in 97 and for those features you create any necessary workarounds.
Don't rely on the converter program in Access to know which features won't work after rolling back to 97.
And check your Tools->References for component issues - a common problem is that the when you reopen the 97 version after being converted you get all missing references to DAO, ADO, Office, Excel, Word, Outlook and other ActiveX components.
My own preference would be option 1 unless you are real good at debugging the conversion from a later version to an earlier one.
Hope this helps.
I wouldn't do this. There are slight differences in the components and no matter what anyone tells you mixing Office Suites on the same PC is not going to run perfectly.
Now I'd make one exception, from my own experience... I have Front Page 2k and Office 2k3. Office 2k3 did not come with Front Page, so there are not two versions of Front Page on one machine.
But when you start Front Page and then start another Office product, they are treated separately as different installations. For example, in 2k, you have an option in the toolbar customization window to put the standard and formatting command bars on one row; in 2k3 the question asks if you want to put these toolbars on two rows instead.
A minor thing but makes my point that you have two sets of components running on the same workstation. And you have to consider that when anything gets written to the registry (even though each Office version has it's own set of keys) that the computer may pick the wrong component at the wrong time.
I don't have the article handy but there was at least one article in the MS knowledge base talking about the risks of mixing the product suites on the same computer. This is why the 2k3 installation will urge you to remove the old apps.
Just a silly question here, but why can't you just upgrade to 2k3? It's a far better product than XP/2002 was.
Maybe someone else on the forum here has better experience with mixing and matching.
Joe: thanks for your response. Caution taken. I have 1 A2K2 app. Quite extensive. 200 tables, 600 queries, 200 forms etc. One customer has clients with A2K2 and a new customer has A97. Will upgrade A97 to A2K3 (because that is what they want). Only want to support one app version so I thought I would do some testing of the A2K2 app under A2K3. Got impatient and loaded A2K3 on same pc as A2K2... installed it to a separate location. Read MS kb articles. Preliminary testing is ok (but I have more to do). Will keep you informed (if you want).
My take on it. I had the same decision to make with my clients. I opted to move to 2k3 clean install which supports the 2k2 and 2k pretty well, with minor mods.
The 97 I opted finally to leave behind (I still have several 97 projects out there at clients but for those I just roll back the source files to 97 before deploying.)
One suggestion: If you are supporting multiple versions, try making your objects generic.
For example, reference objExcel as Object rather than as Excel.Application. You can then move the code to any version of Access without running into the problem with missing or broken object library references. Office products don't roll back very well when links to other object libraries are not found on older versions.
Let me know how it all goes. That sounds like a pretty huge database project! Good luck.
The code is written and been running at one customer for over 2 years. Just signed a contract with another customer and have a third in the wings. I generally use objExcel or objWord, but will double check. Tried a mail merge from A2K3, running an A2K2 db FE and BE into Word 2002. I expected a nightmare, but it worked like a charm. My intent is to continue to develop in A2K2 until I check out the known problems with A2K3, but deploy on A2K2 and A2K3 clients. Will keep you informed. Thanks for your interest and assistance.