Sort objects by size // Remove unused objects (1 Viewer)

[selvsagt]

Hi.
My db has too many objects that is not in use.
I would like to remove probably half of the queries, reports and forms, cause I suspect they are not in use.

Is there a simple way to figure out which objects that has "no connection" from the spashform?

The frontend is about 40mb large, and I would like to speed up launch time, and at the same time tidy up. I figure that if i could sort the different objects by their "filesize" it would be a lot easier to look at the larger objects first and find out if they are in use or not, rather than all the smaller objects.. but for this i need to find out how i see the size... any ideas (its hundreds of objects).

I have looked at FMS tools, but would like to hear yout opinion first...

Btw: I run ms2010 with an sql backend, so there is no data in MSAccess.

 

[Ranman256]

ThIs is dangerous. Ive tried this before And it usually causes error.
Somewhere, something will call a query that is now missing.
I would leave the queries, and only delete tables.
Tables and data is where the bloat is.

 

[jdraw]

If you designed and built it, you have the best info.
A technique that many use is this sort of thing:

Do not delete anything. Backup. (even twice). And only delete from a copy after you have exhaustively tested and confirmed "object" is not used.

Change the name of 1 or 2 things eg: if you have a sub named sParse6, rename to sParse6X.
Test your programs/procedures-- and see if you get a can't find sParse6. If so, you know something uses sParse6. I do this sort of thing with subs and functions when reviewing/cleaning some code.

How do you know this?

My db has too many objects that is not in use.

Have you tried running the Object Dependencies?

Have you run Compact and Repair? (to remove bloat)
I hope it's helpful, but it is very time consuming.

 

[smig]

The only way I know is checking every object for it's Dependencies, and even then tables and queries might be used in some VB code.

 

[selvsagt]

Hi. Thank you for your replies. I guess this would be time consuming, and I probably need to take on form at a time.

In general:
Is it so that a query takes up "zero" size in the db when not in use? If so, then I could leave the queries.
Forms and Reports has logos, pictures, and all kinds of objects on them, and I guess these takes opp a lot of MB's.

To my other question, is it possible to figure out the MBsize of the different objects in my DB? I have looked at all the properties and, and also in the documenter, but there is nothing about object size.

 

[Minty]

It will mainly be the logo's / images in forms and reports.
As a really simple experiment make a back copy and compact repair it to get the true minimum current size.
Delete all the reports with images in them, compact and repair again - note the size difference. It will be pretty large if you have many reports with images in them.

 

[CJ_London]

suggest before this

As a really simple experiment make a back copy and compact repair it to get the true minimum current size.

decompile the database to get rid of loads of vba rubbish - to decompile you have to open the db with the decompile flag set.

e.g. run this

"C:\Program Files (x86)\Microsoft Office\Office14\MSACCESS.EXE" /decompile

then open the db you want to decompile, then compact and repair

you may have a different path to access depending on your version

 

[selvsagt]

Hi. I always decompile when I make a change that requires republishing the frontEnd. So there shouldnt be much rubbish code.

I deleted all reports, forms and macros now, and ended up with 7mb file size.
That probably means that the queries take up 7mb and the rest took about 35mb's.

So back to the question. Is it any way (or tool) to figure out the file size of each object in the database? If i had a list of all forms and reports with "filesize", I could start with the biggest ones and see if they are in use. If not, I delete,, and so on...

 

[jdraw]

I posted a routine here a couple of years back. It is an approximation.