I've only just bought Total Access Analyser (I've got the horrible feeling,
now I've bought 4 FMS products, that I'm going to end up buying everything
they do, and then realise I've spent several 1000s of pounds more than I
would if I'd bought a bundle!).
It looks very useful. And seems especially Access-centric. I suppose it
would be. What I mean is spotting those little errors that are commonly
made. Missing error handlers, forms with the default caption etc. But as a
'this query isn't used anywhere, lets delete it' type tool I think it might
be a bit of blunt instrument. Use with care.
I think Speed Ferret is a good deal more thorough. I think it just works,
basically, on text searches. So if it find "qryMyQuery" as part of a built
up string, as Brendan gives as an example, it'll find it. In a year or so
I'll know better, but for now TAA and Speed Ferret together look like a good
combination.
As is not knocking up forms/queries/reports in a hurry to test something and
then forgetting to delete them afterwards! I look at a couple of apps I've
done and am horrified at how often things called qryTest1 or something end
up staying in the app. Especially if there are a lot of things depending on
it.
Stan Leszyinski has some good little naming tips in his 'Access 97 Expert
Solutions' book (published by Que, but out of print I suspect). Basically
trial objects are prefixed with and underscore - _qryKnockedUpInAHurry,
_frmJustTryingSomethingOut etc. Private ones that will be permanent but
hidden from users he prefixes with a z -
zfrmIUseForExaminingTheErrorLogTable. This is what I do. It's handy.
But....the problem is that 'trial' objects very often end up becoming
permanent ones. I've got some quite complex crosstab queries (well, they
seem complex to me), which are based on selects, which might be based on
other selects. If you start of naming them all with an underscore, decide it
all works fine, it's then a real pain to go through renaming them from the
bottom up. Unless there's an easy way anybody could let me know about. Same
for forms/subforms and the queries they're based on, ditto reports. My
advice is to use proper naming from the start, as though it's for real.
Of course I guess this is one of those things where good outline design
makes sense. We decide before we start building it what objects we will
need, and give them names at that stage. Because we'll never need to change
the design later on. Oh no. Not in a million years. No siree! Once I've
finished an application it never gets changed. Not a chance. Write that spec
then build the app in the next 3 months, without changing so much as a full
stop. That's how we all work. Isn't it?
Yours, Mike MacSween