Which modules are needed

[Catalina]

I have an application that is several years old, it needs some updates and slimming down. I want to weed out everything that is not needed.

My idea is to create a new one and only import tables, form, reports etc. that are needed from the old database.

But what is the best way to determine which modules are needed? I'm sure there are some that I can purge.

My idea is to go into the old application, see where a module is called and find the right one by using the find function in the VBA editor.

Does that make any sense at all? Or is there a better way to do this?

All suggestions will be appreciated.

 

[Ranman256]

no need to do it at all. It would only break something. Leave them. Text does not take up room.
Internal Tables take up room. compact regularly.

 

[sonic8]

no need to do it at all. It would only break something. Leave them. Text does not take up room.

Code is a liability. It consumes the attention and time of the maintainer. It makes perfect sense to purge old code that is no longer needed.

 

[moke123]

But what is the best way to determine which modules are needed?

More than likely you are looking for procedures which are not needed, not modules. A module could contain both needed and un-needed procedures.

 

[ebs17]

All suggestions will be appreciated.

Are you reasonably fit in programming?

When dealing with procedures instead of whole modules:
Registration of the names of the procedures
List all procedures of a module
List all procedures

With the SaveAsText method you can export the complete definitions of all Access objects (forms, reports, macros, modules) to text files.
You can now use a loop to search for the procedure names in the individual text files and note any hits.
Overall, this is probably a bit more structured than a manual search or commenting out and waiting for the resulting errors.

 

[isladogs]

I'd also suggest sorting out your code and indeed other database objects.
You can use Object Dependencies to identify orphan forms, reports, queries and tables
However, that doesn't work for modules.

The following assumes you have Option Explicit on all code modules.

1. Compile your project.
2. Open a module and comment out all the code. Recompile. If it compiles OK, nothing is that module is needed.
If it doesn't compile, restore the procedures that are still used.
3. Repeat in turn with each module.

OR import all objects except modules into a new database. Try to compile and when it fails import what you need.

Which method will be less work will depend on how much redundant code you have.
Much better to keep your project up to date so this situation doesn't arise again in future

OR use a utility such as V-Tools or Find and Replace by Access DevTools or the Dependency Checker addin tool

 

[Josef P.]

Within the code modules the dependencies of the procedures can also be checked with RubberDuck.
To supplement would be possibly still functions which are used e.g. directly in a ControlSource.

... import all objects except modules into a new database. Try to compile and when it fails import what you need.

If this is perhaps also combined with refactoring at the same time, the boy scouts will be happy.

 

[GPGeorge]

MZ Tools includes a "Dead Code Review" which finds unused, or dead, procedures.

 

[Josef P.]

Note: Mz-Tools only lists private procedures in this check, which are not used.

 

[GPGeorge]

Note: Mz-Tools only lists private procedures in this check, which are not used.

Interesting. I had never noticed that it only found dead code in private procedures.

It's also true that it would ONLY find dead code in VBA, not control sources, etc.

 

[GPGeorge]

Interesting. I had never noticed that it only found dead code in private procedures.

It's also true that it would ONLY find dead code in VBA, not control sources, etc.

 

[Josef P.]

I had never noticed that it only found dead code in private procedures.

In private scope.

See MZ-Tools options:

=> find dead code inside procedures, private module variables, ...
But the use of public variables and public procedures is not checked.

 

[isladogs]

That makes sense. It would take ages to check all the code for every public sub / function

Thanks for the reminder about using MZTools for this

 

[gemma-the-husky]

Personally I think with a big DBS you are more likely to duplicate a query or a function, because of the difficulty in keeping track of

Also if a DBS is working well, it's hardly worth the time trying to identify code that could be removed or improved. Often it's just easier to get on with the next project.

Re-engineering apps is difficult for much the same reason. It can be easier to start over.

 

[GPGeorge]

In private scope.

See MZ-Tools options:
View attachment 108743

=> find dead code inside procedures, private module variables, ...
But the use of public variables and public procedures is not checked.

Thanks for pointing that out. I've been relying on my own brand of "misinformation" about dead code.

 

[gemma-the-husky]

@GPGeorge out of interest, what did you do with Northwind V2? Did you start over, or reuse parts of the existing?

 

[GPGeorge]

@GPGeorge out of interest, what did you do with Northwind V2? Did you start over, or reuse parts of the existing?

It's still a food trading company.

 

[gemma-the-husky]

It's still a food trading company.

But did you ignore Northwind 1 and start over, or did you try to redevelop Northwind 1 into Northwind 2? It seems somewhat analogous to me.

 

[GPGeorge]

Seriously, I joined the project after it was underway, so I wasn't part of the initial design discussions.

That said, pretty much every aspect of the application was reviewed and evaluated. There are significant resemblances, obviously. Northwind has an inventory of products which it sells to customers and employees who sell them. Those conceptual things don't really change, although the architecture was recreated.

 

[GPGeorge]

Seriously, I joined the project after it was underway, so I wasn't part of the initial design discussions.

That said, pretty much every aspect of the application was reviewed and evaluated. There are significant resemblances, obviously. Northwind has an inventory of products which it sells to customers and employees who sell them. Those conceptual things don't really change, although the architecture was recreated.

I guess the best analogy I could come up with would be Electric Vehicles. Although they are very different in many ways, they still have four tires, some sort of power plant, some sort of drive train, steering, etc. It would be quite challenging to think up practical alternatives to some of those things. Going back centuries, horse and oxen pulled wagons also had four wheels. Early motor cars were, in fact, called "horseless carriages".

This is a very good question, in fact, because it speaks to the whole nature of a template. Templates are effective, I would suggest, because they encapsulate many, or most, of the features that are common to a class of business operations. If you are tracking operations of a trading company, or wholesaler, you're going to have to include Products, and so on. If you are tracking employees, you need hiring and firing records. Although each custom application can implement them differently, they have to be there.

So, in that sense, yes, NW 2 is the heir to NW 1.