Access 2.0 and 97 nightmare conversion

[Gina Maylone]

Hello all! I was recently handed a db where the back-end was in 2.0 and the front end in 97. I have managed to upgrade it to 2016 and of course it is riddled with errors. As I am going through it and re-writing code to modern day standards, every time there is an error and I debug it and return to the offending form, Access freezes solid. Can't do anything but compact/repair or close and reopen. Any top of the head ideas why this happens? Or solution to keep it from happening. The conversion is taking forever because of it! TIA! Hope your all having a great Sunday morning! (HINT, don't watch the news).

[orange]

It may not be applicable, but a database application with Access 2.0 backend and 97 frontend, would seem to have lived quite a long life. I'd question the continued relevance of the application in its current form (that is the business processes and flow involved).
You know the situation and your role, but it may be an opportunity to research the current requirements against the existing design.
You could spend a lot of time adapting 2.0 and 97 to 2016, only to find the underlying design does not meet the current requirements. If this conversion is also adding undocumented, untested changes and the "wouldn't it be nice to have...", then there may be no reasonable conversion finished date.

There certainly is one aspect of your current efforts that you could comment on --that is the documentation - design, standards, testing materials, training, maintenance and user info supporting the application. How good are what you have? Does the business have any ongoing maintenance of these? What documentation would you have wanted-so now you know what should be created/adjusted....

Good luck.

[CJ_London]

Access freezes solid. Can't do anything but compact/repair or close and reopen

Have you also tried decompiling? May well be a lot of junk hanging around that compact and repair does not remove. Once you have decompiled, do another compact and repair again.

And have you added option explicit to the top of each module and tried compiling the db from the vba editor to pick up on undeclared variables etc?

[NTC]

I imagine it is a nightmare. I tell clients that being excessively frugal becomes expensive - and this is a good example. An unwillingness to upgrade in a timely fashion becomes a problem. At some point a software maker must leave behind old libraries and this time interval leap is surely experiencing that.

I would do things in steps; import the tables into a new 2016 container and then temporarily unsplit it by importing next the queries; these should be no problem at all. It is a lot easier to deal with a difficult upgrade like this in a temporarily unsplit mode.

Then import a single form by form - and work thru each one. Followed by reports. One needs to understand the application in order to know the best order to import things in terms of cross dependencies. Keep track of an obsolete library method's correction on a side document as you'll probably run into it over and over. If there are modules - as these can get called in at any point -so if they exist you need to import them before forms so they exist - but then you'll update them just like you would any other object.

As Orange noted - some things may be totally obsolete - like custom code to create a calendar style date selector which is now of course an embedded feature; so in some cases one rips out the code and replaces the control on the form.

[RuralGuy]

@Gina: Allen Browne has a few thoughts on Upgrading too; down at the bottom of the page under Upgrading: http://allenbrowne.com/tips.html