There are two general categories of errors that can occur in the course of working with dynstructs:
| • | Status-type errors returned from the MX_DYNSTRUCT operations: define, bind, get layout, etc. These you need to explicitly check the applicable return parameters for. |
| • | Run-time ASB errors: |
| • | Error 70, Invalid dynstruct reference, typically means that you are attempting to reference a member of a dynstruct variable that has not been bound to a defined dynstruct. This is most likely a simple programming error, i.e. failure to follow the necessary steps; see Dynstruct's Four Steps. |
| • | Error 71, Undefined dynstruct member, occurs when the member name you are trying to write to does not actually exist in currently bound dynstruct definition. Attempts to read from an undefined member will act as if the member value is .NULL (displays as "<null>"). Any attempt to access an array member without specifying the subscripts will generate the error as well (reads and writes). See below for further comments. |
The undefined dynstruct member error (71) could be a simple programming error, or it could be something harder to avoid due to the nature of dynamically-defined structures whose members can change from one execution to the next. Although you can handle it like all other ASB errors—i.e. via the error-trapping mechanism, you may wonder how to anticipate the possibility so that your run-time code can avoid it.
For the indirect deferred access method, where the member name is obtained from the run-time value of the variable used to hold it, e.g. ds.@fname$, the way to avoid the problem is to always retrieve the layout information—see Retrieve Layout of a Dynstruct—before using it. That information will always be up to date.
That technique won’t help for the simple indirect access method (ds.fname) where the member name is essentially hard-coded into the program, even if it isn’t evaluated until run-time. If, for example, you decide to employ the indirect access dynstruct mechanism as a means of bottom-up security hardening, by removing unauthorized fields from the structures returned by data access functions, any rogue attempts to update those removed members will generate the error 71. But attempts to merely read them value will return .NULL, which is probably ideal in most cases.
Note that if you are undefining structure members to prevent unauthorized access to them, if you also want to retain the original structure size, perhaps to allow writing the record back to the file with authorized updates, then you would need preserve the member definitions (i.e. preserve the layout) but change their names to prevent them from being used. That might be a less than perfect means of protecting those fields, since they would still be visible by retrieving the layout information, but the assumption here is that the access is still limited by the existing application logic. The objective of bottom-up hardening of this type not being to prevent all programmer access but to prevent accidental user access from existing parts of the application.
