Feedback about cross version compatibility

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?

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!