[AccessD] Rick Fisher F and R a panacea?

[Bill Benson]

Getting a little off topic from the previous thread to do a deeper delve on
F&R.

I am probably going to be labeled the most skeptical person ever - if not
an outright PITA, gadfly, and public nuissance, but ...

Any time a tool is touted and I see pitfalls with it, I am going to
challenge, Jim, and it is not personal. If you feel they are baseless or do
wish to comment, feel free, but this is just one programmers opinion and
caution.

I agree that tool is useful, but no panacea. The developer must check
everything he or she possibly can to be sure the tool did it's job
correctly as well as think hard about what the tool may have missed. It's
probably a good starting point but I would keep backups. Using it on an
inherited DB which I did not explore personally every nook and cranny of
before letting *some tool* make global changes to its innards, would leave
me anxious about future problems.  Perhaps not unmanageable, but problems
neverthelrss. Lots of things in my DBs seem to be not used but they will
be, some how. Although to be truthful I do try to test for their presence
and create them on the fly, if missing. One of the things I cannot recreate
with VBA are attachment fields, so I would be very careful deleting tables
you think are not in use, if they contain multi-value fields,  since
doubtless the program is not creating them on the fly.

I assume by used, Jim means no other object depends on them at design time.
I often re-purpose objects in VBA which otherwise seem unused, such as
subforms bound to empty forms having their recordsource changed to other
forms through VBA at runtime.

I am sure the tool has great value, but I would be extremely careful with
it.  Particularly where VBA code is involved, such as when an sql string
written

  StrSQL = "SELECT * FROM SomeQuery" must become  strSQL = "SELECT * FROM
[Some Query]".

Another concern I might have: There are many properties in Excel that are
read write but when you start writing them, you run into limitations you
did not expect (or a novice wouldn't expect) like formulaarray having 255
character limit. So one cannot read a formulaarray property, change a
defined name that array formula looks up in,  from "Small" to
"NotVerySmallAtAll", and expect to be able to put back the same array
formula into the FormulaArray property of a cell. Might there not be
similar issues for F & R I cannot help but wonder, with respect to Access
limitations. Access might be the same way. Would F & R forward tests it's
ability to change all dependent properties before beginning the changes, or
just fail and bail mid - change without rollback?

On Feb 7, 2016 5:18 AM, "Jim Dettman" <jimdettman at verizon.net> wrote:
>
>
>  What's really useful in there is the cross reference utility.
>
>  A lot don't even know it's there.  With it, you can list every object in
> the DB not being used.
>
>  Takes a couple of passes to drill down and get everything, but when I
take
> on an old DB, within a few hours I can have all the junk ditched.
>
> Jim.
>
> -----Original Message-----
>