There's a TH out in a couple of days that might help: Trap Form Errors

It then all depends how you handle those errors, do you save them to a table, log them to a file.

"On Error Resume Next" ignores errors so you can't log those, naturally.  To log errors, you use "On Error Goto ____" to transfer execution to an "error handler" that you wrote for that procedure, and that is where you log the error.  The error number and description are stored in Err.Number and Err.Description, which you can store in a log table if you want to.  Their values are cleared after "Exit Sub".  That means you need to put this code into every procedure in your database.  This is a daunting task if you have lots of procedures.  There is no "global error handler." You have to write this code for every single sub.

And yes, I've done it in my old job, and it was no fun.  In addition, you have to make sure execution is able to continue (or not) after an error is trapped.  Transactions may have to be rolled back, and variables may have to be cleared or reinstated.  Creating a "global error handler" is a like a second project on its own.

It might be the next project within the database. I think it would be better to put it in a table so you could track it.

Some pointers if you've never done this before:

The picture below shows the error handling I used in my old job.  I have a form that shows the detail of the logged errors: the name of the procedure where the error occurred, the "line number" of the error, the error number and description.  The "line numbers" are the "10:", "20:", etc., as shown in the VBA code below.  When an error occurs, the line number that just precedes the error will be stored in the "Erl" variable.

Each procedure should always start with "On Error GoTo", naturally, in order to trap all possible errors inside it.  I use "On Error GoTo err1" below.  When an error occurs, execution will go to the portion of the code labeled "err1:" as shown below.

Important: the "err1" section can NOT have any error.  If an error occurs there, the "On Error" at the top will take effect AGAIN and send the execution back to the start of "err1," causing an infinite loop of sort.

That is why I use only procedures under "err1" -- because other procedures can have their own error-handling.  Always use procedures, not "loose code," inside an error handler.  E.g.:

Use only procedures:

     err1:
          RecordErrors A, B, C
          ShowCustomMsg "Here is a friendly error message..."
          ...
    
Do NOT use "loose code":

     err1:
          If A = B Then C = D
          For E = F to G
              H = I
              J = DLookup(...)
          ...

You could also log to the Windows Event Log

vbs
Set shell = CreateObject("WScript.Shell")
shell.LogEvent 4, "Your Message Here"

MSDN: LogEvent

The event log is specific to each individual PC, whereas a custom-made log can be stored in a remote, shareable database.

Another tip is that you need to able to turn on or off the error handling.  You need to turn it off to debug the app, and turn it back on for your users.  So every sub needs a line like this:

    If ErrorHandlingEnabled Then On Error GoTo ....

which runs "On Error" conditionally based on a global setting.

So many options... so little time...