With the recent flurry of Access 97 articles and editorials you may be wondering, “What does it take to make the move to Access 97?” I have to answer that question with a question: “Where are you coming from?” If you’re upgrading from Access 95, the road to Access 97 is pretty short. Although Microsoft has once again changed the .MDB file format, you should have little problem moving existing Access 95 applications forward. The only new hurdle is that most Access 97 properties are now strongly typed (instead of the variant data type). For example, you’ll have to change any code that sets a caption to Null.
While moving from Access 95 to Access 97 is pretty smooth, more than likely you’re contemplating a move from Access 2.0 to Access 97. Unfortunately, the conversion from Access 2.0 can be a bit more involved. In essence, you’ll meet the same obstacles that developers who moved from Access 2.0 to Access 95 have encountered. This may be a good time to dig out your copy of the Complete Smart Access CD. Several articles in the November 1995 issue of Smart Access covered most of the issues. You may want to start with Mary Chipman and Mike Gunderloy’s overview entitled “Converting Access 2.0 Applications to Access 95.” Another useful article by Ken Getz appeared in the January 1996 issue (thereby just missing the cutoff for this year’s CD). You may also wish to check out Mike Gilbert’s recent article (October 1996) entitled “Developing Applications in a Dual Platform World.” Obviously I can’t repeat the text of all the relevant articles here, but I’ll highlight some of the key issues you need to consider.
Before you convert
Before you start the conversion process, it’s important that you open up your 2.0 application in Access 2.0 and compile all your modules, including form and report modules. If you encounter any syntax errors, fix them now before you convert. If you don’t compile your apps before converting, the conversion routine will likely hiccup and fail to properly convert your code.
If your database has many objects (the exact number depends on the memory of your machine), Access may report an “out of memory” error during the conversion process. If this happens, you should abandon the unfinished conversion, create a blank Access 97 database, and convert objects in batches of around 50 objects by directly importing the objects from the Access 2.0 database.
The most painful aspect of the conversion process will be converting 16-bit API calls to 32-bit API calls. None of your existing 16-bit API calls will work! You’ll need to rework all of them to the equivalent 32-bit API calls. Ken Getz wrote in detail about this subject in his January 1996 article, “It’s a 32-bit World Out There: Converting 16-bit API Calls to Access 95.”
Other issues to consider include the use of obsolete DAO syntax (remove it), 16-bit custom controls (remove the controls and use the 32-bit equivalents), and secured applications.
Another thing to consider is whether to spend some time taking advantage of the new functionality. Otherwise, why bother with the conversion? Now would be a good time, for example, to start integrating the new VBA constructs, the Tab control, class modules, hyperlinks, ODBC Direct, and other new features into your applications.
