Solved New detail records being added despite disabled button in master form

  • Thread starter Thread starter Deleted Bruce 182381
  • Start date Start date
I've been away for a few hours.
Yes I do have code that does all that and have used it in more than one commercial app with a time-limited evaluation version.
However I've not published the system date check code online.

What I will share is my notes from that code including the link that got me started:

Code:
'https://stackoverflow.com/questions/48371398/get-date-from-internet-and-compare-to-system-clock-on-workbook-open

'You will need to do this in steps

'Get UTC time from internet
'Convert UTC to local time, taking into account DST
'Compare tho PC clock
'Apply a tolerance
'UTC time functions from cpearson.com

Here is a list of the procedures I used:
1764891401558.png


I used some of the code provided without modification but also made changes elsewhere
 
@BlueSpruce
What is the business driver for employees to enter these contracts?
Is this something that management can control with proper rules?

I am guessing someone is doing this to pad their pay. If this is true, proper response from management should be termination of the employee for cause. This may be far more effective than what you are able to do in ACCESS.
 
None of the code in the answer in that thread is Excel specific
 
They're some of my customers users, and I have a fiduciary duty to protect my customers to the best of my ability.

Exactly, one cannot totally prevent fraud from occurring. There's only so much validation that can prevent users from intentionally entering wrong data, and fraud can occur by simply not entering any data at all. I have been advising certain customers from a management consulting perspective on how to discover who is committing fraud.

Some customers are single users on one desktop, and some operate entirely offline.
For your customers with employees, properly securing the computers will help but if you suspect fraud, Access BE and possibly FE is the wrong tool. Let the owner know what's happening and what can be done to detect and possible prevent it.

For single user customer, explaining the issue should be sufficient after the FE is adjusted. If the owner of a business want's to cook the books, there is nothing you can do to stop it.

Some detection could be added with data macros, auditing table updates and logging.

Audit link
 
I last used this code around 2018 and can't remember the details of what I changed / added.
I don't have the time to go through and check for differences.

The reason I'm not sharing my code is that without spending time to check (which I don't have), I'm not sure whether that would undo the security built in to the commercial apps where it is used.

However, my memory is also that none of the code that I used was originally Excel specific.
Suggest you read the SO thread and the related article from the late, great Chip Pearson and compare the list of functions in each with the list of functions provided in my screenshot. I know many (possibly all) of the APIs came from Chip's code.

As for your final question, if the computers are always offline, none of this code will be any use whatsoever.
That wasn't an issue for the apps I was protecting as they required internet access for part of their core functionality
 
Last edited:
For your customers with employees, properly securing the computers will help but if you suspect fraud, Access BE and possibly FE is the wrong tool. Let the owner know what's happening and what can be done to detect and possible prevent it.

For single user customer, explaining the issue should be sufficient after the FE is adjusted. If the owner of a business want's to cook the books, there is nothing you can do to stop it.

Some detection could be added with data macros, auditing table updates and logging.

Audit link
Ron has shared a link to a presentation I made last month.

I should note that after that meeting, I encountered a limitation that might be a show-stopper for anyone interested in going down this path.

Specifically, one of the tables in the database I used has two Long Text fields. I had already found that Data Macros do not have the ability to retrieve the Old value of Long Text fields, which is the value you need to log "prior to change" and "post change" values in the Audit Log. I had implemented a VBA supplement to work around that limitation.

During further testing, I encountered an additional limitation that is the show-stopper. If a Long Text field contains more than ~2,034 characters, Access locks the record in which it appears and VBA cannot retrieve the value of that Long Text field prior to the change.

So, one way or the other DM or VBA, auditing Long Text fields, where values can potentially exceed the ~2,034 character mark, is simply not automatable.

Work-arounds could include always caching the entire value of Long Text fields before any attempt to change the record, so the cached value can be retrieved, if necessary, for the audit log. Another could be to log only the first 255 characters. A third could be to ignore Long Text fields. None of those seems appropriate to me.

So, instead, I went to a full VBA auditting approach.

Here's my conclusion regarding "Simple" audit logging.

1764940866789.png
 

Users who are viewing this thread

Back
Top Bottom