Convert to Access 2007 - Is Usage Experience Relevant?

By Thomas Eklund

How relevant is Access 2007 usage experience to application development?

Some discussions that I have had indicate confusion over how relevant is Access 2007 usage experience to actual expert-level application development. This article is based on these discussions and the relevant correspondence.

Based on my previous experience, I believe the following to be true and highly relevant.

Access 2007 does have new features. However, if you will primarily focus on making sure, that the developer whom you will hire has Access 2007 experience, or Access 2007 conversion experience, you may end up with a rather poorly functioning outcome.

Consequently, both the users and other people involved will end up with a lot of grief.

Here's what you want to keep in mind, when converting applications into Access 2007.

The Access to Access conversion itself is as easy as it was before, during the earlier versions of Access. For the most part, it involves simply opening and saving the file in the new format.

Access 2007 uses a new file format, accdb, vs. mdb. The new file format cannot be opened in earlier versions of Access.

In my opinion this is a somewhat superficial difference, because essentially similar restrictions applied in many instances before, too, especially when pre-Access 2000 versions were involved. However, it is something to keep in mind. Prior to converting an application, we want to make sure, that all users have Access 2007 available and that their hardware (RAM, CPU) supports the application as well.

If linked Access databases are involved, we want to convert all of them at the same time and re-establish links, where needed.

Replicated database conversion requires extra steps, but can be handled successfully as well.

Here's what I would recommend you to focus on, and why.

Based on my experience with Access conversions, the problems are usually related to development-related mistakes that were made when previous version's applications were built. These features, that were built less than properly, may not function as needed in the new environment.

In some instances, the problem and the solution are simply technical in nature.

In other instances, specific users requirements are involved, which need to be taken into consideration when the application is set up in the new environment.

In such cases, instead of making assumptions, the developer should seek to understand, what the feature must accomplish and then make sure, that it is built properly in the new environment.

If you anticipate, that you may need some development work done as well, make sure that you hire a developer who is experienced in all the needed areas.

Relatively few MS Access developers can handle equally well all the diverse database application development tasks. Successful application development, however, relies on all of the needed areas coming together in a complementary manner.

It is much more likely that you will end up with a well-functioning application, if the developer handles on expert level all the necessary MS Access development-related tasks: project management, business analysis, application architecture and navigation structure development, usability engineering and user interface design, table structure and other objects development, programming, quality control and user training.

If you need to transfer data from flat-file environment (for example, Excel or FileMaker) to relational database environment, different type of challenges may have to be handled skillfully. This applies to both previous version of Access and to Access 2007 as well.

Expert level Access developer doesn't necessarily have to have any direct Access 2007 experience, to be a superbly well qualified candidate for handling your needs successfully. An expert can learn any necessary Access 2007 related knowledge quickly.

However, more importantly, when you hire a database development expert to develop relational database applications for you, that expert should possess a very necessary mix of skills and experience, that is obtained through working in the relevant fields for a number of years.

At least to some degree the same applies when the developer is hired to convert database applications from an earlier version to a newer one. The conversion itself is rather simple. So, if you actually need to hire somebody for such tasks, chances are that more work needs to be done than simple conversion of Access applications.

For example, in my opinion Access applications should be built so, that the users do not need to know any Access at all, that is, they do not need to have any Access software usage knowledge at all. None whatsoever. In addition to entering data when needed all they need to know, is in what order to click buttons on the custom developed user interfaces that the developer has set up for them. At least the applications that I build work this way. Any searching, filtering, data manipulation, reporting and business intelligence features that I custom develop for Access applications are way easier to use and work way better than what's built into Access software originally.

(Of course, no offense is intended to any of the people who have worked at Microsoft on building Access software over the years. Building Access software and developing software using Access are two different things.)

For example, I can add business intelligence tools (Report Center), so that the application users can create their own queries on the fly on application relevant subject matters in countless different ways, without the users actually having to know how to create SQL based queries in Access. The resulting data sets can be viewed on screen or put into another software, like Word or Excel, or attached to emails (as mail merge letters) dynamically on the fly.

A brief side note: of course, this is not Access specific - the same can be done using other relational database software packages as well. Most of what is described on this website and the previous work examples that are provided are not Access specific and apply to usage of other relational database software packages as well.

Even such a functionality part like, for example, User Guides that I custom build is way better than the one that is built into Access software, because I can set up the User Guide so, that it contains content that is customized for the specific database application, opens up so, that no matter what user interface is opened, the User Guide, when opened, shows automatically content for that user interface (that is, the content that is displayed first changes depending on what user interface is opened), and either one (admin user) or all the users can also easily modify the User Guide content and add their own application usage related notes to it.

User Guide on its own is, of course, relatively insignificant, but hopefully it helps to illustrate that hiring a developer who can successfully handle the different relational database building aspects is well worth it.

For additional relevant examples please take a look at Custom Developed Workflow Software and Business Process Software and Previous Work subsections.

Of course, there are many great Access developers out there. So, the point of this article is that it's worth being selective about whom to hire. Hiring a good relational database developer is well worth the money. When you are not hiring an entire development team, where different team members cover the different application development areas and aspects, then hiring a person who can do an expert level job in all the relevant areas is an excellent idea - if you want the application users to work with a productivity increasing, good quality, highly usable end result.

Taking these developer selection principles into consideration will benefit the application users, the employer and, therefore, also people who are involved in the hiring process.

Top