Check a DB for unused tables, queries & forms (1 Viewer)

shenty

Registered User.
Local time
Today, 13:47
Joined
Jun 8, 2007
Messages
119
Hi all

Is there a way to run a 'check' on all tables, queries, forms and reports in a database to find out whether they are actually being called somewhere either via a Record Source or as part of a VB Event Procedure etc etc. ?

I have a db i've been working on on and off, and you know how it is when you create some test forms or queries etc then end up using them.....i daren't delete them incase they are not actually redundant..:(

Any help would be nice.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 07:47
Joined
Feb 28, 2001
Messages
27,444
You can do this but it takes some VBA.

Access defines a series of collections. Tabledefs, Querydefs, Modules, Documents, maybe a couple of others of lesser significance. Access Help on collections is available and not that hard.

In essence, you can write a VBA routine to scan the other collections to see what tables are called out in them.

If it is in Tabledefs, it does you no good to scan because after all, you are looking for a table reference. Well, in Tabledefs, you WILL find the table definition you were seeking.

In Querydefs, you will see queries that give you table names and field names. Or you can look at the .SQL of the querydef and parse out the contents of the FROM clause and the JOIN clauses. You can make your VBA code write out the table names and the names of the referencing query. When you see queries beginning with ~ as a query name, they were created by one of the form or report wizards when you used that wizard rather than doing a direct design.

In Documents, you will find closed copies of various forms and reports, which you have to open in design mode in order to examine. (In an otherwise inactive database, the Forms and Reports collections should be empty because you don't have any potential members of either of those collections open.) When you do open the document, you can see the recordsources for those forms and reports that are bound. You can also see class modules, which are normally stored as lines of code, line numbers restart with each module. See next topic for parsing...

In modules, you have the headache. By stepping through the Lines() collection in each class or general module, assuming it is an MDB and not an MDE, you can see the code as strings which can be parsed if you are patient enough. This is NOT for the faint of heart, but it is possible to look for certain things like OpenRecordset and the domain aggregate functions, each of which COULD have a table reference. You can also have an ExecuteSQL that names a table in the referenced SQL string, though that is a totally different can of worms if the string is built dynamically.

Other than that, I think you would have to look for a commercial product to do this kind of analysis for you.
 

shenty

Registered User.
Local time
Today, 13:47
Joined
Jun 8, 2007
Messages
119
thanks for the reply - it gives me something to search on.

thanks again
 

LukeChung-FMS

President, FMS Inc
Local time
Today, 08:47
Joined
Nov 20, 2008
Messages
17
Hi Shenty,

This is a very complicated analysis to perform on your own or manually. Objects can be referenced in a variety of ways in an Access application. Finding unused objects involves locating everywhere objects are being used and then comparing it to all your objects to see which ones aren't.

Even that analysis isn't complete due to objects that can be used interactively and therefore shouldn't be deleted, and the many ways objects can be referenced with code that can't be absolutely resolved.

I recently updated a paper on this subject entitled Finding and Deleting Unused Microsoft Access Objects and Code (http://www.fmsinc.com/MicrosoftAccess/UnusedObjects/FindingDeleting.html)

The paper talks about this process and how objects are referenced by other objects. It also discusses how our commercial product Total Access Analyzer (http://www.fmsinc.com/Products/analyzer/) can find this information automatically, along with many other things to improve your Access database development and maintenance. In fact, finding unused objects and VBA code was a significant driver for why we created the Total Access Analyzer originally. Hope this helps.

Good luck,

Luke Chung
President
FMS, Inc.
http://www.fmsinc.com
 

boblarson

Smeghead
Local time
Today, 05:47
Joined
Jan 12, 2001
Messages
32,059
Hey Luke -

Nice to see you here at AWF. Welcome!

It was great to get a chance to meet you last week at the Dev Kitchen.
 

LukeChung-FMS

President, FMS Inc
Local time
Today, 08:47
Joined
Nov 20, 2008
Messages
17
Thanks. Happy to be here. Likewise, it was nice meeting you.

Sorry we didn't get to spend more time together. Thanks for your support of the Access community. Let me know if you'd like to review any of our products, and how we can help you and the community.

Luke
 

Users who are viewing this thread

Top Bottom