Feedback about cross version compatibility

Greg Lindhorst (Program Manager on the team) is looking for customer feedback on the impact of some new features on cross version scenarios. Love to get some feedback from the community about a few questions we have:

    1. How important is it that previous versions of Access can RUN applications (launch forms, change data values) written in a newer version of Access?
    2. How important is it that previous versions of Access can EDIT applications (modify forms, change data schema) written in a newer version of Access?

Your feedback is greatly appreciated.

Office Blogs Comments

Comments: (49) Collapse

  • Edwin Blancovitch said on January 9, 2009 6:45 PM: A2007 is NOT fully compatible withe previous versions of Access. Thus A2003 has no direct continuation.

  • As a solo developer, it is not practical to have more than about two development machines. And it is necessary to have the lead machine always have the latest version of Access. But it takes time - even years - before my client base catches up. Today, most apps that I support (and about 1/2 of new apps) are Access 2003 (MDB) format. What is imprtant to me is that I can support - from the current shipping version - one version backwards, preferably two - from the lead machine running the current shipping version. I don't distribute MDE's, only MDB's. To date, I've had no problems supporting 2003 apps (to include writing new apps) with the lead machine using 2007 and Vista Ultimate. Fortunately, the VBA references fixup themselves when the app is distributed as an MDB.

  • In terms of backward compatibility:

    * If 2 versions of access can run on one machine, then I'm fine with the present handling of backward compat. * As long as the newer version can import the older files (and upgrade them) as is the situation at present, then that is fine. For forward compatibility:

    * By this I assume you mean that the newer version of Access has the ability to save files in earlier version formats. This is a nice feature, but I would rather drop it, than hold back development of *useful* (and coherent) new features.

  • We write an Access app used in 40+ countries. Most of our users are on 2003 and migrating to 2007, but we do all our compiles in Access 2000 for maximum compatibility. Targeting a single version is not practical. If we were to develop in 2007, I would wonder if it was really perfect for users of earlier versions, even if it nominally was supposed to work. What I REALLY want to see is the return of user level permissions. I know they are not as robust as server based models, but that doesn't mean they aren't crucial to the success of an app. Where higher security is required developers can incorporate other more robust approaches. In conclusion I want to point out that while it's fine that Access works better with SharePoint that before, that is a niche use. The client server model can't perform well enough or be reliable enough for a big global application. Sometimes you just gotta have distributed data, and Access should provide that.

< Previous  1 2 3 4
Comments

Comments: (loading) Collapse