Feedback about cross version compatibility

We are operating in a large organization and do not distribute our Access programs to clients in other organizations. In this controlled environment we do not see a need for older versions to be able to run or edit newer versions of Access.

These two questions only ask about how older versions work with newer versions and from that perspective neither is important to me at all. For me it comes down to the data ... as long as I can get to the data (tables) saved in an older version file format then I am OK . I work for a large organization and I typically only need to support 2 versions of front end during transition periods (I have about 500 unique users for my applications across a 1500 person community)which can take months. After the transition period I 'upgrade' the back end data files. All in all not that big of a deal.

I think that it is very important that older versions of Access can run a programme written in the latest version. There should be a runtime version option which selects the version of Access the programme will be run in. Then, if an older version is chosen, the parts that will definitely not run in the chosen version should be disabled. Customers can not always update to the latest version due to costs but the Developer should be able to create programmes for any version. It would be impossible for older versions to edit programmes created in the latest version unless none of the improvements or additions were implemented in the programme. If you could edit newer versions in the older version then it would mean that no-one needed to buy the newer version so the problem would never arise.

Vote for 1. and 2.: Not important for us. Our applications are so complex that we are glad if they run in the version they are written with. And as long as they also run in a newer version without the need for large changes (like creating ribbons which alone took us 2 months) we find that sufficient.

I dont' care about being able to edit databases from previous versions. But I have many cases where the users are still running Access XP or 2003 and I do all the editting in 2007. I know I could install the runtime version for them, but why should I have to mess with that if they already have an older full version?

I develop Access applications for multiple organizations, and I can't fully control when they upgrade their version of Office and Access. Thus it is critical to me that multiple versions of Access be allowed to run safely on the same machine without any problems. This is not the case with Access 2003 and Access 2007, and has prevented me from moving many organizations up to 2007. Here is my priority list of backward/forward compatibility: 1. allow multiple Access versions to coexist peacefully on the same machine. 2. newer versions of Access support running applications developed in older Access versions. 3. newer versions of Access support modifying applications targeted at older versions. The newer version allows you to either disable new features that would break the application in older versions, or provides warnings when any action will raise compatiblity issues. 4. older versions of Access support running applications built in a newer version of Access, as long as it sticks to compatible features. 5. older versions of Access modifying apps built in newer versions of Access is not needed. To me, #1 and #2 are critical, and I was greatly disappointed that Access 2007 did not meet these minimal requirements. Thanks for your consideration of this feedback!

Dave

My focus is providing packaged applications that do not permit design changes by the end user. These two capabilities would solve my issues: 1) Allow any version of access (full or runtime) to be installed and run on the same system without conflict. This would allow a mix of old and new apps to coexist until either apps are upgraded. It would also allow those old, never to be upgraded, apps to exist with the new apps. You have little control on the versions of access any user would need based on the apps being used, but could provide a runtime at any level for use with specific apps. 2) Newer version of access should support running of prior version access formats. If this worked consistently then only the latest runtime/full version of access would be needed to run current and existing apps. Given the fact that older versions of access can be used for the design, the following option would be useful but can be gotten around. 1) Older versions of access being able to run applications built with newer version. (Assuming no feature issues) Not needed at all if item 2 above worked: 1) Older versions of access being able to modify apps built with newer version. If you want to design for the new version get the new version.

#1: Low importance if there is a free run-time. Otherwise medium importance if the new version offers significant new functionality. #2: Low importance. Power users would have the newer version.

1). Not important at all. As long as there is a model to automate the new versions, compatibility isn't really required in that direction. 2). Even less important. If preserving upward compatibility is going to prevent some new features and technologies from the new version of Access, then ditch upward compatibility altogether. Access still has too much of a foot in the past and doesn't benefit from all the nifty and damn useful technologies other development platforms enjoy.

Yes Yes Yes.. We require full compatibility with earlier versions and of course future versions. In my case , we are totally dependent on Access to serve our clients so we need to take care of the scalability issue and also need not miss out the feature upgrades in newer versions.

It seems yours two questions have spawned a slew of answers to questions not asked - but really important. For me, being able to run and/or edit an Access 2007 database from anything before Access 2007 is not necessary - I wouldn't really expect it. There are features available in Access 2007 that are not in prior versions - you'd have to program for that and I feel it would be a waste of time and talent that could be better used elsewhere. If a client doesn't have Access 2007 then put the Access 2007 MDE in with a run-time... but only if it will not interfere with prior versions of full and run-time installed. This is the big problem. I agree with other comments here that have multiple full and run-time versions of Access running on the same system, without interference, WITHOUT RE-INSTALLATION NOTICES, with reference problems, is far more important that getting Access 2000 run to an Access 2007 database. Give us the ability to run Access 2000, 2003, 2007 databases as if they're blind to each other. And not only development version but runtimes as well so we can test and make sure we're not going to kill a client's existing system. The recent hotfix released makes no mention of how it will affect a run-time system so I, for one, am paranoid that it will disable my database under the runtime - I can't install the hotfix and need to. We need more cohesive releases and fixes - release a development hotfix AND a runtime hotfix - or at least tell us that the hotfix addresses both the dev and runtime versions AND that it will not acces prior Access versions. Your questions speak to cross-version compatability from old to new but you haven't built in something more important.. new to old without re-installing. David K

Our work with Microsoft Access (since 1.1) has been in developing vertical market applications. Eventually we retire our development efforts for a particular version of Access once the majority of our clients have moved on to new versions of Office/Access. So at any one time we support 3 or so vesions of Access. But the march forward continues. At the current time we develop in Access 2003 and recompile for Access 2002 (because it allows us to and it is easy) and 2007. We are comfortable with Access 2007 and will eventually embrace it as our development version. If providing cross-conversion compatability means retarding the introduction of wanted features in future versions then my team would oppose the ability.

There are a lot of comments with the mention of runtime. This seems fine if no changes or amendments are to be made. But when changes are required, I think question 1 is pretty important. I note that you mentioned RUN, but the thing is what if it doesn't just quite, what happens? Due to the plethora of versions, I would think backward compatibility going back at least 3 versions is in order. I am not too sure about question 2. For instance, Access 2007 allows for over 1M rows f data in a table. How would an older version handle that?

Hello Access Developers. . . Happy Holidays, happy New Year. . . Like one of the guys said, access development should not be designed based on version compatibility. I have seen a lot of access applications created in 2003, which are being used by 2007 runtimes. Microsoft has done excellent work with backward compatibility. "Keep on doing your best guys" And older version should never edit a newer version, it will break it. Keep like you do now, this database was created in a newer version, and just close. However, a newer version should be able to read and write to older versions, like you do now. You have a good design now. NOW . . . that being said. . . I will like to tell you something that will be wonderful, you have a deployed working version of your app, you go to a client, that is in recession and you fix/optimize some code, and you just need to quickly install this new version. GOTCHA!! You have the new version, and the client has the old version . . . now you need to install the runtime, and have some problems from versioning issues. I think the access should just do, create a full compatible previous version MDE, so you can just quickly install to your client. Of course, it will remove any new feature.

And you have a fully functional compile mde that will work in previous version and everybody is happy, of course that means a lot of development from the Microsoft guys.

Hello again Access Developers! Yes Ms access is developers best friend in db development but notorious when deployed! but what if MS will make Access deployment like in delphi or C/C++,he.he.he. All MS Access developers are very happy except "SAGEKEY". All the above issue will eventually vanished....Conflicts,versioning..others because we can deploy an independent executables... MDE to EXE, We can use what ever version as our development platform!..