It is possible to see bogus data when you PRINT a report or SELECT from a VIEW. It must be the second time you access the VIEW, and you usually have a different sort condition on the second query. The bogus data displays because of the combination of the row width, number of rows selected by the view and how the data is placed in the pages of the SCRATCH files. Sometimes high order ASCII characters will display on the report, but when you look at the data in the tables it is fine.

The simplest solution is to DISCONNect and CONNECT the database between commands to remove the old R:BASE scratch files.

Here are a few tips to automate the cleaning process of R:BASE scratch files in your application.

01.   Use the following process in your application startup file:

   Example 01:

   SET ERROR MESSAGE 2262 OFF
   SET ERROR MESSAGE 2926 OFF
   ERASE *.$$$
   SET ERROR MESSAGE 2926 ON
   SET ERROR MESSAGE 2262 ON

02.    You may also use the following technique to manage R:BASE scratch files your way!

   Example 02:

   -- AppStartupFile.DAT
   DISCONNECT
   CLEAR VAR vChkFile
   SET VAR vChkFile INTEGER = NULL
   SET VAR vChkFile = (CHKFILE('C:\TEMP'))
   IF vChkFile <> 1 THEN
    MD C:\TEMP
   ENDIF
   SET SCRATCH C:\TEMP
   SET ERROR MESSAGE 2262 OFF
   SET ERROR MESSAGE 2926 OFF
   ERASE C:\TEMP\*.$$$
   SET ERROR MESSAGE 2926 ON
   SET ERROR MESSAGE 2262 ON
   CONNECT dbname IDENTIFIED BY userid password
   QUIT TO YourAppMainMenu.RMD
   RETURN

This technique allows you to define your own R:BASE SCRATCH directory as well as the freedom of reading, writing and deleting scratch files on the local workstation without being concerned about the user rights and allocated space on the network or mapped drive, when working in a multi-user environment. Using this technique, you are also aware of the exact location of R:BASE Scratch files for manually cleaning the TEMP directory on local hard drive.