Tip of the Day: Managing R:BASE Scratch Files
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.
Very Best R:egards,
Razzak.
