The WOMBAT was added to DATATRIEVE by
Jim Starkey and Ann W. Harrison.
(Jim's explanation of how this came about was archived on Dejanews,
but it was lost when Dejanews was taken over by Google.)
Following Jim Starkey's lead, the newsletter of the DATATRIEVE SIG of
DECUS was named The Wombat Examiner and then changed to The Wombat Examiner and
4GL Dispatch when the role of the SIG expanded to the support of other fourth generation
The simple answer is that DATATRIEVE is not slow.There are two situations where DATATRIEVE
may appear to be slow. Procedure activation and procedure execution.
DATATRIEVE (prior to Version 7.0) used CDD, the Common Data Dictionary, to store
it objects. Retrieval of information from CDD can be quite slow. One needs to create
a balanced binary tree of objects and nodes in the CDD to optimize retrieval. Since
Version 7.0, objects can be stored in RMS files or in memory. Procedure activation
is significantly faster. For this performance enhancement, you may thank Federico M. Macchi.
DATATRIEVE accesses data which is stored in RMS files, Rdb databases, DBMS databases,
and several other formats. Execution of procedures against data which is stored in
improperly designed files or database can be quite slow. Execution of programs written
in 3GLs have the same performance problems when performed against poorly designed
files and databases.
Send your question by using the E-mail below.
If the answer is of general interest, I'll put it here.