Reading Errors after ACCESS calls

1

It is well known that the following code is wrong;

If Access:table:Whatever <> Level:Benign
      lastError = Errorcode()
   End

This is because the ABC Methods explicitly do not preserve the actual ErrorCode et al from the file driver operation. So you cannot test ErrorCode(), Error(), FileErrorCode() or FileError() after an ABC call.

The Errors are however pushed into the GlobalErrors object, and hence can be queried. So the following code works;

If Access:table:Whatever <> Level:Benign
    lastError = GlobalErrors.GetError(ErrClarion)
    lastErrorCode = GlobalErrors.GetErrorCode(ErrClarion)
    lastFileError = GlobalErrors.GetError(ErrFile)
    lastFileErrorCode = GlobalErrors.GetErrorCode(ErrFile)
   End
2 Likes
2

One possible problem with that, is if the GlobalErrors object is not properly synced throughout the DLLs.

That’s where the “Try” methods might be more reliable at giving you a correct answer by allowing you to read those ERRORCODE() values directly, since they don’t step on the state of the ERRORs.

An example of a non-synced GlobalErrors would be a UtilityDLL that is used by other DLLs but might not have been used by the EXE, so there’s no DLL Init call, passing the GlobalErrors and IniMgr to sync the objects. This means the DLL uses its own independent objects, and not the Filemanager ones.

Easy to fix, but easy to miss too.

3

I don’t believe this is true. I’m not aware of any contract that suggests the TRY methods are always going to preserve the errorcode. Obviously they don’t necessarily stomp on it, but I don’t think tyou can rely on this.

2 Likes