OpenEdge creates temporary files during each client session. Each operating system has different temporary files. The following table describes the temporary files.
Table 24. Temporary client session files
File
Description
.dbi
Stores temporary tables
.lbi
Local before-image file (subtransaction undo)
.ped
Edit buffer contents
.rcd
Cache of r-code being run in a session
.srt
Temporary sort space; session compile storage
.trp
Stores Data Dictionary changes until they are saved
By default, OpenEdge stores the temporary files in the user's working directory. Use the Temporary Directory (-T) startup parameter to specify an alternate location. When a session ends, OpenEdge deletes these files unless you specify the Save Temp Files (-t) startup parameter. For more information about the Temporary Directory (-T) and Save Temp Files (-t) startup parameters, see OpenEdge Deployment: Startup Command and Parameter Reference.
On UNIX, unless you use the Save Temp Files (-t) startup parameter, you do not see the temporary files in the directory because they are created unlinked. However, if your system crashes, the UNIX file system recovery program, fsck, finds the files. This program might then prompt you to delete the files. If this occurs, delete them.
On Windows, these temporary files are always visible during an OpenEdge session, but the file sizes are set to zero. Windows does not record file sizes until files are closed.
Writing to these temporary files creates I/O activity that might slow down client performance. The amount of temporary file I/O activity varies among applications.
You might find that running a particular procedure results in OpenEdge abnormally terminating in a way that indicates the hard disk is full. However, when you check the disk immediately afterward, adequate space is available. One possibility is that temporary files created during an OpenEdge session become quite large, taking up disk space as they expand. Since OpenEdge erases temporary files at the end of a session, they do not appear when you check the disk. Of the temporary files, the following files are most likely to cause this problem:
Temp table file (.dbi) — OpenEdge uses this file to store temporary tables. If the application uses a lot of temporary tables, this file can grow quite large.
Local before-image file ( .lbi ) — OpenEdge uses this file to back out of subtransactions and variable value changes. If the local before-image file becomes too large, the procedures probably use a lot of subtransactions. Examine the transaction structure of the application procedures to understand why OpenEdge starts so many subtransactions. For more information about transaction processing, see OpenEdge Getting Started: ABL Essentials.
R-code swap file ( .rcd ) — OpenEdge uses this file to dynamically swap r-code segments in and out of the execution buffer. Use the r-code usage statistics startup parameters to collect information about I/O to the swap file, as explained in Monitoringr-code activity. Using procedure libraries helps reduce the amount of I/O required to load r-code files. For more information, see Using procedure libraries to improve r-code performance.
Note: The AVM swaps codepage-converted text segments for procedure libraries from the execution buffer to the r-code swap file and reloads the converted text segments from the swap file instead of the library when necessary.
If temporary files grow to exceed disk space, change the application to reduce the size of temporary files, or use the Temporary Directory (-T) parameter to store the temporary files on a disk with sufficient space to hold the files. To optimize performance, place the temporary files on a dedicated disk.
Temp table file (.dbi) — OpenEdge uses this file to store temporary tables. If the application uses a lot of temporary tables, this file can grow quite large.