Dec 092017
Technical information on Paradox memory mangement. Written in reference to Paradox 1.0, but most still applies to 2.0 and 3.0.
File MEMMGT.ZIP from The Programmer’s Corner in
Category Paradox DBMS
Technical information on Paradox memory mangement. Written in reference to Paradox 1.0, but most still applies to 2.0 and 3.0.
File Name File Size Zip Size Zip Type
MEMMGT.TXT 3847 1623 deflated

Download File MEMMGT.ZIP Here

Contents of the MEMMGT.TXT file



Paradox 1.1 employs a very sophisticated virtual memory system. The
following information may be helpful if you have received "Not enough memory to
complete operation" messages.

Although 512K is enough memory to start Paradox, some operations can exhaust
available memory. Therefore, it is often helpful to have 640K of RAM in your
machine. Most, if not all of this memory should be allocated to Paradox.
Terminate-and-stay-resident (TSR) programs such as Sidekick and RAM-resident
print spoolers can seriously interfere with Paradox operations.

Put simply - The more RAM memory is available to it, the more efficiently
Paradox will operate.

Paradox Memory Usage

Paradox internally segments the available memory in the general memory pool
into an image pool, a procedure pool, and a variable pool. You may determine the
amount of memory available in the general memory pool with the following steps:

o Select the PAL menu with Alt-F10 and select Value.
o Type memleft() followed by a carriage return.

Paradox displays the remaining memory in the general memory pool in a window
on your screen. You can use memleft() as a function in any PAL scripts you may


Image space, the space taken by images on the workspace, can
significantly affect the amount of memory available. The space taken by a single
record on the workspace is calculated according to the following:

Numeric and Dollar fields 22 bytes
Date fields 12 bytes
Alphanumeric fields 1 byte per character
Short integer fields 10 bytes

The default space taken by an image is 22 times the record space.
Accordingly, wide tables can dramatically affect the operation of Paradox. To
minimize the effect, always normalize tables as suggested in Chapter 6 (Create)
of the Paradox User's Guide.


Procedures also have a large influence on available memory. Procedures,
when played or read into memory, take up space until a RELEASE PROCS command is
issued. RELEASE PROCS returns memory to the procedure pool for other procedures,
but does not release memory back to the general memory pool. The PAL MEMLEFT
function, which reports the amount of memory currently available in the General
Memory pool in bytes, can be useful in tuning a memory-intensive application.
MEMLEFT takes no arguments. Because it was added to Paradox in Release 1.10,
MEMLEFT didn't make it into the documentation; therefore, it is not as widely
known as it should be. The MEMLEFT() function is documented in Release 2.0.

Only a RELEASE PROCS ALL command returns almost all space to the general
memory pool. Therefore, be sure to call procedures only as needed and always
release individual procedures at the same level after they are used. You should
never release a procedure or issue a RELEASE PROCS ALL command from within the
named procedure.


Normally, the amount of memory taken by variables is insignificant. Paradox
allocates space for memory variables much as it does for procedures. The release
of variables returns space to the variable pool, but not to the general memory

Variable space is not returned to the general memory pool until you exit
Paradox. Accordingly, it is not good practice to build huge arrays. (Note:
Paradox stores arrays at 4 bytes per element).


To best manage memory in Paradox 1.1, reduce the width of your tables, and
promptly release procedures and variables. If memory problems persist, call Ansa
Customer Support for further advice about your specific situation.

 December 9, 2017  Add comments

Leave a Reply