[AccessD] Audit Trail Suggestions

Arthur Fuller fuller.artful at gmail.com
Sat Mar 14 16:28:17 CDT 2015


Not in the slightest to poo-poo your most significant contributions to the
Access community, but your class is of interest only to the (perhaps large)
number of users who still use Access as the BE in their app of interest.
We've traversed this path many times, and the clear result is that this is
the wrong way to design and build apps, unless said app is really trivial,
meaning fewer than 20 tables.

As for me, I'm concerned with databases comprising 100+ tables. Now and
then, for some friend, I will knock off a simple (less than 20 tables)
solution, but that's not my zone of comfort. I prefer complex situations.
I've done more than a few that involve 500+ tables. That's my comfort zone,
and where I can bring some knowledge and experience to the table.

Admittedly, these apps are infrequent, but they are the ones that I hold
out for. The really tough problems are the ones I love: gene-analysis, and
so on. Way back when, I coined an abbreviation, YAFOES, which means Yet
Another Forking Order Entry System. No matter how much money you're
prepared to toss my way, I am most emphatically not interested in such a
gig. Call me uppity if you wish, but at my age and my level of experience,
I choose not to travel down that familiar path. I have in mind much larger
problems, with much larger implications for the world at large.

I want to figure out how to deal with the problem of kids on the street,
whose parents have discarded them because they declared themselves LGBT or
whatever. That's just one example. Also include the victims of domestic
assault, and the very limited number of shelters they can turn to, and the
shame they feel that prevents them from turning to such a shelter for help.

These are not, I realize, problems that Access developers typically
encounter in one day's work. But I've been in this game for a long time,
and now that I'm semi-retired, these issues have become of paramount
importance. I have volunteered to work for several organizations whose
mission pertains to this topic.

So it may be that for the next little while I won't be able to respond
immediately to messages posted here to me.

Right now, it's time to go there.

On Sat, Mar 14, 2015 at 4:44 PM, John W. Colby <jwcolby at gmail.com> wrote:

> I wrote a class set to handle this.  Feed in the control to the class and
> then watch the events.  Log changes.
>
> John W. Colby
>
>
> On 3/14/2015 12:21 AM, David Emerson wrote:
>
>> Hi Team,
>>
>> Looking for ideas for implementation.
>>
>> Access 2010 FE, SQL 2008 R2
>>
>> A client wants to keep track of some fields in some tables when they are
>> changed.  There are over 50 tables involved and anywhere from 3 to 30
>> fields
>> per table.  The tables and fields are predefined.  Most of the data
>> changes
>> will be done via Access screens but there are some fields that are changed
>> through code
>>
>> When a field value is changed they want to store in a log table date,
>> person
>> making change, old value, new value.
>>
>> Looking for ideas of how others might have tackled this type of problem
>> before.
>>
>> Regards
>>
>> David Emerson
>> Dalyn Software Ltd
>> Wellington, New Zealand
>>
>>
>>
>>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>



-- 
Arthur


More information about the AccessD mailing list