Obsolete objects in database

[Leo_Polla_Psemata]

Hi
I have developed an access data base which meets my needs and wants in a very very large extent.
I didn't make it in one shot, no, I started three years ago, I made several adjustments, then it happened to come across this site which boosted my knowledge and skills so I changed the design of many objects, i made them better
I changed the technique as I used little VBA .
Now I know that in the data base, some objects are obsolete.
I can delete them but there is always a fear that this object feeds some other query and most likely after some time i will discover that something doesn't work, so, just removing objects , even if look obsolete, is always a threat.

Question.
If i just leave them sitting there, does this makes the whole database going slowly or it doesn't matter ?
If I go through and carefully check and delete, will I see some improvement in respond time?

 

[CJ_London]

If i just leave them sitting there, does this makes the whole database going slowly or it doesn't matter ?

doubt it will make any difference except to the size of your db

If I go through and carefully check and delete, will I see some improvement in respond time?

possibly, depends on what the objects are and whether you parse through them

Personally I would delete them since they just clutter up the environment. Providing you have autocorrect turned off, you can rename them (I put a prefix of zz_) so they all gather at the bottom. If the application continues to work OK you know you can delete them

You also have the Object Dependencies option to see if an object is used by another object although this won't pick up references in code - for this just use find to search the code for an objects name

 

[Leo_Polla_Psemata]

Hi
Size up db, okay, if runs smoothly, no big problem.

I can rename them but the dlookup doesn't go well with renames.

Does "Object Dependencies" detects dlookup's and if a VBA uses a part of a query with another part of another table/query just to work ?

 

[speakers_86]

I think it's best to just leave it alone. If you really want it gone, make a backup first, then delete the items. Do plenty of testing afterwards, too. Probably a good idea to decompact and compile afterwards, too.

 

[CJ_London]

Does "Object Dependencies" detects dlookup's

No - and certainly not in VBA

 

[Galaxiom]

V-tools

Use the Total Deep Search to find any reference to an object before you decide if you should delete it.

 

[MarkK]

What I do is rename the object by prefixing it with "zz_". Then, if after a few months everything still works fine, I delete it.

 

[speakers_86]

I think MarkK's answer is the best. Just make sure all those name correction options are off, and make a backup before you go renaming a bunch of stuff.

 

[Galaxiom]

What I do is rename the object by prefixing it with "zz_". Then, if after a few months everything still works fine, I delete it.

Of course it would be essential that Name Auto Correct was turned off before doing this or the references to the object in queries would be automatically renamed next time they were run.

NAC is on by default.

 

[Galaxiom]

I think MarkK's answer is the best. .

Rename and hope is too much reliance on luck for me. Firstly there is a real chance something could be used once a year and be deleted before it is used again. Secondly the problem is only found when the process fails for a user. Very poor user experience.

Searching for all reference with V-Tools is a reliable solution that doesn't affect users. It searches the Union queries, RowSources and VBA which are not done by Object Dependencies and is completely free so there is no reason not to use it.

BTW Compact and Repair after deleting each object or you may get an error on the next Deep search.