Microsoft Access Team Blog

I think it is important because on the whole it makes transitions from version to version easier and smoother. Once I tried to offer an application to someone that had a previous Access version installed on their computer, and they didn't want to upgrade for various personal reasons that involved company politics and such. So it didn’t work. If he would have been able to try working with it, and would have liked it, and then learned that with a newer Access version’ the application may have some improved functionality, perhaps he would have been convinced to upgrade his office suit. You can always say that if my demonstration was good enough and if my application would have fit his needs, that should have sufficed to convince him to go ahead and upgrade, but I still think that it would have been easier on both of us if the option to use my application on his install was available, and chances are he would have liked it.

As far as I know, other office applications maintain this ability from version to version, probably for good reason. I read here many times that Access is part of Office, and end users are being considered etc… I think that should apply here as well.

Similarly, I think that it will be very helpful if a run time of a newer version would be able to work smoothly on the same machine with an Access install of a previous one.

I guess my answer refers especially to question number 1 above.

Gilad

I would also like to take this opportunity and ask about version 14. When are we going to get some information about what is planned? For me this will be a test version and if it will not be able to answer my needs sufficiently I unfortunately will not be using Access any more. I know that the world will probably not be heavily affected by this transgression, but I will. And if I am a sample user of Access then that may mean something, because others are in a similar stance.

I am tired of the “End User Argument”, by which, when someone complains about lacking functionality the response is: “You must understand that there is a whole different class of customers that we must also consider”. When it is a developer complaining then this different class of users consists of “end-users”. When it is an end-user complaining then the same reply is provided, only this time the different class of users consists of “Developers”. When in fact I think Access 07 , with all its bells and whistles an hoo’s and haa’s , was really oriented towards neither. If any, I think the class of customers that were actually considered are the Access team themselves. They built the application to suit their own vision of what is best, leaving many disgruntled customers behind, end-users and developers alike, some of which tried to voice their complaints here in this blog.

Perhaps this comment should be addressed to whoever is leading the Access team. Some one out there is the responsible one. I didn’t notice he or she was addressed here ever.

I personally am looking for backward compatibility, the ability to distribute the application and its upgrades easily and simply, a complete solution that includes the ability to easily develop and code the ribbons without needing third party tools, the ability to choose if I want to work in a new interface or not. And only then will any added new functionalities, half baked or not, be appealing to me.

Best wishes

Gilad

I still write apps in Access 2000 format to retain compatibility with earlier versions of Access prior to 2007.

One of my worries is that older apps may not work in future versions of Access.

Garry

For first question, it is important as said by Gilad. For second,  it is not important.

I think the same way as above, that it would be better to have the ability for older versions of Access to run newer ones, but generally the editing is only carried out centrally, so this is less of a problem.

To clarify the reasons for my 'vote' for option 1:  We have around 40 workstations, some that can run Office 2007, and some that we either haven't got the disk space, or are too slow (don't get me started on the boot speed with Outlook 2007!).  At the moment I have had to standardise on Access 2003 across the board, although I have Outlook 2007 in use for the WSS features etc.  Ideally on those machines that can run it, I would prefer to use Office 2007, but I don't want to keep two versions of the databases, nor do I want to run the 2003 version on the 2007 program.

I also have customers to whom we supply databases to for pricing purposes, who use different versions of Access to each other, which is a right pain.

I concur that I would like to see Access 14 back to something that WE want.  For example, removing security as it is in 2007 was just unbelieveable when a developer needs to secure the program, regardless of the data.  

Perhaps the Access team should consider something that sometimes happens with Dynamics, where a survey is available, listing a load of features and possible options, where the Access user/developer base (perhaps the first question would be "what type of user are you?") can use a quota of points to vote for what they see as important to be developed.  With something like that, at least we can see the possible routes that might be taken, and we all feel "part of the team" as otherwise I think the general consensus is that we are not valued.

I too am considering other options other than Access development, so if MS carry on with the user-centred plan for Access to make it simpler for users (perhaps we need two products nowadays, one to attract people that would otherwise use Excel, and one for the rest of us) I think I will be looking elsewhere.

As a developer, I have found that I have to maintain virtual machines with each version installed, to be able to maintain compatibility for my applications.

I got sick of modifying a 2003 application in 2007 and then having to perform on-site modifications to get it to work because of incompatible references etc.

The real problem that I see is the development road plan changing with overambitious expectations of what they could actually deliver.  eg. "JET will disappear", "DAO will be completely replaced by ADO",  etc.  The consequence of this seems to be holes left in what is delivered when the new version comes out.

In my opinion it's not nescessary to be able to run or edit MDBs that have been created in newer versions of Access. Much more important is that MDBs written in older versions of Access can at least be run on newer Access versions or even better be edited in the old file format in newer Access versions (at least for the last 3 Versions).

I'd be more concerned that newer versions of Access could run older applications without problems. I write most of my applications for non-profit organisations, and development timescales can be rather lengthy. I'm still working in Access 2003, but worry that some clients will get new computers with Access 2007 that won't run applications under development or in use. Clients rarely understand that when problems arise between versions it is outside the developer's control.

On the other hand, the ability to run newer versions could also be useful, since it would enable me to move up to, say, 2007 for development, if I could be certain that 2003 would run the application without problems.

I was very unsure about the Access 2007, because of the new Access format.

Upwards compatibility is one thing, that is really missing. I assume, that you focus on the problem, if newer Version of Access databases can be modified in A07. Would be great! I like compatible things, but it has to work, to make sense.

The downwards compatibility works nice and smooth, asides from changes in the vba version, the reference mess up (Open A03 in A07).

I use A03 and A07 because of different programms I wrote for my customers and the support and further development makes it easy, if you have a downwards compatibility and just one version of Office on the PC.

Forgot to mention that if security does come back, one of the biggest annoyances I have with upgrading is having to recreate security workgroups from scratch for the newer versions, or so that would need to be cross-version too.

Thanks for the oportunity to comment on this.  In my experience, MS has done a great job in maintaining backwards compatibility for Access versions since A97.  A few exceptions I can think of involve the file format differences like adp vs. mdb in A2000 and now accdb vs. mdb in A2007.

This is fine for devs, IMHO, because we know to just stay away from the new format in mixed version environments.

The features to convert or create compatible mdbs versions in A2003 work great.

There are features in A2007 that seem to crash the app when you try to save design changes to controls in a 2000 compatible mdb.  THis is a shame as I have grown to trust the backward compatibility designing in A2003.

Running older MDBs in future versions is a must.  Designing them should be a must, unless your team wants to set a new precident for disapointment.

If design changes to old versions cannot be made in future versions, then installing multiple versions of access on the same computer is required and needs to be an important part of the quality testing and must be supported by MS.  This is not the case beginning with A2007.

Setting up Virtual Machines for designing Access apps because of a failure to maintain backwards compatibility and a lack of supporting multiple installed versions is silly.

Short answer:  Maintain full compatibility or resolve and support issues with installing multiple versions of access on the same computer.

Josh

As someone that uses Access 07 with others that us Access 03 this is greatly important.  

For me, running apps is of the utmost importance. I can write in any version but the issues of writing and app in one version of Access and then finding that either the app won't run or it will run but not in ways I intended are both very frustrating. I can think of several companies I know of who had released relatively full featured apps using Access and the jump to '07 by many of their clients has broken them.

IMHO, newer version should be able to run older version apps.  For developing, newer versions need not be editable in older versions.

Being able to run older version with the latest version is a must have...I cannot seem to convince all customers that they should use the same version of Access on all computers...the cost of upgrading gets in the way.  Maybe having a Access runtime as part of the OS would fix this.  That way the only computers that need upgrading are people doing development.

If I have to develop for clients with multiple version I use a virtual computer with the lowest version.  Of course all users get their own frontend, so that references are not a problem.

It's a classic case of I wouldn't start from here.

If it is possible to build backward execution of Access apps that would be desirable. But will it be possible to build that in in anything but the most immediate predecessor? It would be a good thing if all access apps would run on all access installations no matter what version but unless someone has a time machine how will that happen.

On the other hand I can't see why you would want to be able to allow any version of access to edit applications functionality by changing the programming in earlier versions.

I'd guess that in general, developers in larger organisations, will have access to the latest version of Access before users and that this could be seen as a way to stop users "tinkering" with the software as it is shipped and therefore almost a security feature.

Not related to the original question but in response to earlier postings...

I think that more effort should be made for new versions to ALWAYS support ALL previous versions so that the code, screens, tables, views etc from older versions can be retrieved and modified into a shiny new version using the DB engine and storage file suffix of the newest version. Although the specifics above relate to Access I'd say the same about all products including languages such as VB but I guess that boat has already sailed and sunk!

Not related to the original question but in response to earlier postings...

I think that more effort should be made for new versions to ALWAYS support ALL previous versions so that the code, screens, tables, views etc from older versions can be retrieved and modified into a shiny new version using the DB engine and storage file suffix of the newest version.

Although the specifics above relate to Access I'd say the same about all products including languages such as VB but I guess that boat has already sailed and sunk!

I think it’s very important that previous version of Access can run applications created in a newer version.  I always developing in the oldest version we have running.  This method prohibits me from taking advantage of any of the new features, which in turn limits my users on the newest version.

On the other hand, editing the application in a previous version is not important to me.  I disallow my end users from change anything.

Agree!  #1: Critical!!! And not just MDBs, but MDEs as well (why is an A07 MDE incompatible with A03?)

#2: Not so much.  

And (with Neil Jordan) ... Bring back ULS!!!

Thanks

Pretty important to be able to run applications. I work at a large company (150K) with hundreds of locations which means we have Access 2000, XP, 2003, and 2007 in use. It would be nice if our IT org could standardize, but with so many sites and developers, this isn't always possible!

I consider both features important, but #1 > #2 in importance.

--rj

Although I appreciate the advances in the 2007 UI from a development standpoint, the reality is that, whatever version I use to develop an app, it needs to run on older versions.  Graceful degradation of nifty UI stuff is acceptable, but as others have pointed out, either maintain backwards compatibility, or give the developer a means of targeting/testing for a specific platform/version (think compatibility modes).  If you aren't willing to grow the product as a serious development tool, then let us know so that we can give up on it.

I think you posed a very difficult question to us (and thanks for doing so). I would frankly guess that in this case Microsoft would have a great perspective on the question, because you already have a pretty good track record on this issue, and also because if you're asking us about it re A14, there must be a reason you're considering your options, which we're not privy too.

Bare bones I'd say #1 is important and #2 is less so.

But what I'd say in verbose mode is: if you give us a developer lovable version of Access (you must know what we mean by that now) then I don't give a brass farthing whether it's backward compatible or not. That is, if you're going to actually grant the wishes of developers and get us a tool that deals with the many shortcomings of Access 12 and gets us the many missing features that we've been pining for during the past decade, go for it. I can imagine both budgetary and programmatic simplifications if you were able to start from a clean slate and not worry about backwards compatibility.

There are a host of great things that could be done with Access 14, like beatific integration with SDS (hope we hear more about that soon, huron), and I'd rather have Access focus on the new stuff, if it's developer oriented, than the old stuff.

Pretty sure you won't take it that far. Just looking and the requests for max/strong compatibility above, don't see how you can dodge the bullet. But take this as a vote for new developer features over nth degree backward compatibility.

How can beatific be spelled that way and not beautific? Strange. Can you fix that too? <g>

A version of our software is based on one Access version. Therefore it is not necessary to run or modify forms with an old version. But we share data in tables between more than one version. It is important that we can use the tables in more than one version.

Thomas

can you provide more info on Access 14, or when can start to know more about Access 14...

I think when we update the program to a new version, not all the clients do, so it is important to have.  However, at what cost?  if this means functionality that is vital to keep moving Access forward, I vote no.  It is important to keep Access moving into the future and the things you guys have been working on look great, so I would not sacrifice these upgrades too much for this aspect.  If we have a new program written in a new version of Access, then we will either have to "run time" it or have the client side update to the newer version of Access.

I would not like to see Access' development being held back by backwards compatibility issues. Access 2003 is a great version and I have several apps wirtten in 2003 that meet the users requirements and I have no plans to upgrade.

However for new developments I am now encouraging customers to go for Access 2007. Given that the runtime for Access 2007 is now free I am getting less resistance from users to go for this option, especially given some of the nice out-of-the box functionality which saves on development effort and cost.

As long as new version of access can read data out of old versions I don't have a problem.

There been quite a few posts in the newsgroups about people deploying older versions of access (2000 to 2003), but using the a2007 runtime (I suspect that now that this developers tool is free for us, that has something to do with this!). So the feedback I’m seeing in the newsgroup speaks quite well for backward compatibility.

Most applications will run well even when you launch them in a newer version of access anyway.

So, to answer #1 – yes, this is valuable. You could mitigate this problem by continuing to ensure that the runtime is available for a given version perhaps?

For Editing, and modifying, it is important. I suppose one could convert to new version…edit….and then convert back? Perhaps the better question is how much do we need the “save as” to previous versions, and this we really need.

I do find that during the transition period when I ONLY have 2007 on my new computer that I do a lot of editing of older mdb files in 2007. We not taking about sharing the mdb files with other people, but JUST ME using the mdb files. I have so many that I don’t want to convert them all, I just want to work, and over time I will upgrade them eventually to 2007..but, this it will take time.  

During this period I don’t do a lot of major modifications and editing of that application, but I will do some small ones. If I am going to do a LOT of work, then I will convert it to 2007.  So, my use case scenario is not really a lot of transferring between each version, but it is convenient to do some small editing and not having to convert the older version to the new version UNTIL  I’m going to do a lot of significant amount of work to make it worth the time to actually do the conversion. So, this is a single user (me) case scenario that occurs during the transition period.

In a typical office information worker environment, this above use case scenario would likely be a little bit different.

It’s a question if the transition period is also more formalized.

There are ways to deal with upgrades and backwards compatibility overtime in an organization One of my clients had to upgrade 25 computers, but only 3-5 of them per week. Thus, we had to run my software on older computers, and also run a newer version of access. Of course I was also working with several other vendors in that office, and they’re all saying boy you’re gonna have the most problems trying to run two different versions of access on all these computers in the office, just you wait, you are in big trouble!

Of course at the end of the day, we were running a split system in which we installed the older version (front end) of  my application on the older machines, and the newer version (front end) on the newer machines. They were all connected to a shared back end data file.

It turns out that of all the vendors for that upgrade, the access applications were the LEAST problematic of all the vendors involved and we had the last laugh!

In other words they were trying to upgrade other applications like Maximizer and other third party applications which did not work together when you ran different versions on different computers in the office, especially when they’re trying to share data on the servers – their upgrades turned out to be a nightmare!

So, using the right approach with MS access we actually had a more seamless and trouble free rollout of new applications, and we had FAR less problems than any other vendors during this upgrade.

Albert D. Kallal

Edmonton, Alberta Canada

KIS- Allow MS ACCESS Application to compile into EXE! Like Delphi or the best model out there was Thinstall in terms of Headache free deployment..Access is developers best friend in db development but notorious when deployed!

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!..

Unfortunatelly, we have no chance to test Office 2007 SP2 beta Czech (CZ) language version since CZ is not available. I have created a database with Access 2007 bugs & issues & suggestions while ago, see www.alis.cz/relax/download/access/Access2007_bugs.rar, and I have passed the database to Mr. Bechynsky of Microsoft CZ. We were said that some people were looking into the database - but we have no report/response/feedback for about two months now. That's why I decided to post a link here so that there's bigger chance that some bugs will be fixed in SP2.

We're now going to test the most important issues in MSO 2007 EN Trial + SP2 beta. It may take several weeks - I'll create bug reports as soon as we have some results from beta-testing. Anyway, I'd like MS US to look into the database and eventually contact Mr. Bechynsky of MS CZ to check out what's going on.

The database includes attachments (images, docs, videos). Attachments can be downloaded separately from

www.alis.cz/relax/download/access/Access2007_bugs-A.rar.

There's a PDF extract available at

www.alis.cz/relax/download/access/A2007bugs.pdf.

Any updates to the database will be published at www.alis.cz/relax/download/access/Access2007_bugs.rar immediatelly.

File sizes (as of Nov 29th 2008):

Access2007_bugs.rar     30.970.150 B

Access2007_bugs-A.rar     59.360.347 B

A2007bugs.pdf          1.399.371 B

There are a few videos in the attachments showing that Access 2007 is NOT compatible with previous versions (A2002). It's risky and

dangerous (!!!) to run older MDB/MDE projects under A2007 since A2007 fails in some occasions, eg. forms'/reports' filters may not work OK, forms with subforms may not work at all, etc. At the moment there's no direct continuation to Access 2003 (or previous versions) since VBA-code/forms/reports are not compatible. Also, there are very serious bugs in Package Solution Wizard - ie. MSI files will not

install what you need. All of these plus new MSO 2007 GUI (ribbon/navigation pane/missing classic menus & toolbars & database window) plus poor help system make A2007 a non-RAD tool.

We need A2007 to be compatible with any previous version. If a A2007 project will be saved in A2002 format all A2002's functionality is expected to be 100% OK.

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.