# Reading Errors after ACCESS calls

**URL:** <https://clarionhub.com/t/reading-errors-after-access-calls/9054>\
**Category:** tips\
**Tags:** abc\
**Created:** [April 18, 2026, 3:15am UTC](https://clarionhub.com/t/reading-errors-after-access-calls/9054 "2026-04-18T03:15:52Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Bruce](https://clarionhub.com/letter_avatar_proxy/v4/letter/b/ccd318/32.png) [@Bruce](https://clarionhub.com/u/Bruce)\
**Post date:** [April 18, 2026, 3:15am UTC](https://clarionhub.com/t/reading-errors-after-access-calls/9054/1 "2026-04-18T03:15:52Z")

</div>

It is well known that the following code is wrong;

```clarion
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;

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

```

---

<div class="post-metadata">

**Author:** ![jslarve](https://clarionhub.com/letter_avatar_proxy/v4/letter/j/e480ec/32.png) [@jslarve](https://clarionhub.com/u/jslarve)\
**Post date:** [April 18, 2026, 3:57am UTC](https://clarionhub.com/t/reading-errors-after-access-calls/9054/2 "2026-04-18T03:57:36Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Bruce](https://clarionhub.com/letter_avatar_proxy/v4/letter/b/ccd318/32.png) [@Bruce](https://clarionhub.com/u/Bruce)\
**Post date:** [April 18, 2026, 4:46am UTC](https://clarionhub.com/t/reading-errors-after-access-calls/9054/3 "2026-04-18T04:46:46Z")

</div>

> [@jslarve](#):
>
> 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.

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.