Feedback about cross version compatibility

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.