[AccessD] A diff program for Access?
rockysmolin2 at gmail.com
Fri Nov 12 09:53:23 CST 2021
I have the old mdbdiff program which works on mdb files and works well on
tables but does not do code. I can send it to you if you like.
I really miss Fisher's Find and Replace. That program was a gem. I used it
a lot back in the day and could have used it this year looking for
occurrences of something across all objects. But, he's gone and my copy of
F&R stopped working.
Finding subs and functions never called is easy - just do a global find in
the VBA editor of the sub or function name. If it doesn't appear anywhere,
I agree with you about passing parameters to a called form versus grabbing
the needed value from an open form. So now I use code:
DoCmd.OpenForm "frmActivityComments", , , , , , Me.fldMAID
where fldMAID is a Marketing Activity, and form frmActivityComments is a
table of comments associated with the marketing activity.
in frmActivityComments the open event has the lines:
Me.Filter = "fldMAID = " & Val(Me.OpenArgs)
Me.FilterOn = True
to set a filter in the called form.
Or to find a specific record:
If Not IsNull(Me.OpenArgs) Then
Me.RecordsetClone.FindFirst "fldDiscussionLeaderID = " &
Me.Bookmark = Me.RecordsetClone.Bookmark
I began using this approach when I found that a form in my app could be
called from more than one place. So instead of using the IsOpen function to
find out which form it was, I instituted a polocy of always passing the
parameter of the record or the filter from the calling form.
On Fri, Nov 12, 2021 at 6:27 AM Arthur Fuller <fuller.artful at gmail.com>
> I don't suppose there exists such a thing, but who knows, there may be. I
> want to determine the differences down to every level between App A and App
> B. Is there a tool that can do that, or am I forced to walk hand by hand
> through hundreds of modules, forms, queries and reports.
> This app has grown gargantuan over the years, and this is a very bad thing.
> Perhaps the first thing I need to do is identify all the "dead code" -- old
> subs and functions never called in the current implementation
> Next, I want to employ a technique I learned from Jim Dettman: forget the
> behemoth app model and instead create Microservices that do one thing, such
> as deliver a report. On occasion, this is not trivial: Access seduces you
> into thinking that reference to some open form are cool. I most
> emphatically disagree. If a Report needs parameters, then pass them, or
> alternatively refer to the return values of Static Functions.
> I think that I may be going against the stream here. So be it. I like to
> use the Access Wizards to create the basic code, but immeiately after that
> I separate the generated code for the button from the button itself,
> creating a new sub or function and changing the btton code to cal that Sub
> or Function. as a result, al the form/button-clicks are reduced to one line
> of code, not dependent upon the form whose buutton invokes a local event.
> NOT my way of coding. I choose to ship everything possible away frrom the
> form and refereences to its avlaue, and eventually all the code away from
> the form into a module that I can call from anywhere, given expected
> AccessD mailing list
> AccessD at databaseadvisors.com
> Website: http://www.databaseadvisors.com
More information about the AccessD