[RBASE-L] - Re: Setting Scratch, scratch files and R:Base crashes

[Jim Limburg]

Alastair

I have had good luck with this code:

SET VAR vg_temp TEXT = NULL
SET VAR vg_temp = (ENVVAL('TEMP')) --See if TEMP is defined in Environment
IF vg_temp IS NOT NULL THEN
  SET SCRATCH .vg_temp
  SET VAR delfiles TEXT = ('ERASE ' + (CHAR(39)) + .vg_temp + '\' + +
  '*.$$$' + (CHAR(39)))
  SET MESSAGES OFF
  SET ERROR MESSAGES OFF
  &delfiles
  SET ERROR MESSAGES ON
  SET MESSAGES ON
ELSE
  --Since most of our machines are W2k
  SET VAR vg_dir INTEGER = (CHKFILE('C:\WINNT\TEMP'))
  IF vg_dir = 1 THEN
    SET VAR vg_temp TEXT = 'C:\WINNT\TEMP'
    SET SCRATCH .vg_temp
    SET VAR delfiles TEXT = ('ERASE ' + .vg_temp + '\' + '*.$$$')
    SET MESSAGES OFF
    SET ERROR MESSAGES OFF
    &delfiles
    SET ERROR MESSAGES ON
    SET MESSAGES ON  else --c:\winnt\temp does not exist, try another route.
    SET VAR vg_dir INTEGER = (CHKFILE('C:\WINDOWS\TEMP'))
    IF vg_dir = 1 THEN
      SET VAR vg_temp TEXT = 'C:\WINDOWS\TEMP'
      SET SCRATCH .vg_temp
      SET VAR delfiles TEXT = ('ERASE ' + (CHAR(39)) + .vg_temp + '\' + +
      '*.$$$' + (CHAR(39)))
      SET MESSAGES OFF
      SET ERROR MESSAGES OFF
      &delfiles
      SET ERROR MESSAGES ON
      SET MESSAGES ON    else
      SET VAR vg_temp = (CVAL('CURRDIR'))
      -- will be the directory the database
      -- is in since we are connneted
      SET SCRATCH .vg_temp
      SET VAR delfiles TEXT = ('ERASE ' + (CHAR(39)) + .vg_temp + '\' + +
      '*.$$$' + (CHAR(39)))
      SET MESSAGES OFF
      SET ERROR MESSAGES OFF
      &delfiles
      SET ERROR MESSAGES ON
      SET MESSAGES ON
    ENDIF
  ENDIF
  CLEAR VAR vg_ver, vg_dw
ENDIF
So far I haven't had any real problems with the scratch being local, and
whether it comes up with temp being set to somthing like
C:\Documents and Settings\jlimburg.SERVER1\Local Settings\Temp
or
C:\TEMP
or
C:\WINDOWS\TEMP
it has worked well
I do have another 2cent-opinion .. I have used Crashguard, and as
a network admin, and user (home), I eventually threw it out the window.
I have to admit, I haven't used the latest version, but I know for sure
that approx. 30% of the crashes it reported, I could trace back to
crashguard itslef being the problem, and that to me makes it useless.
I can't say I remember the exact ways I traced this out, but I know for
sure it was about a year ago that I stopped using it altogether, and
even though I don't have it's reporting issues to help with other problems
I have had a lot less problems, especially when I took it off my home Pc.
Jim

Alastair Burr wrote:
I'd like to sound out the list's views on what goes on with scratch files:

As you all know, I've had endless problems with R:Base crashing since
changing from Dos to Windows 2 years ago.
You also all know that a couple of things have recently made significant
differences to the crashes, namely:
1) Changing a file extension from .DAT to .$$$.
2) Removing the SET SCRATCH C:\TEMP setting.
Currently, I still get a few crashes but nowhere near as many. However, I
noticed today that CrashGuard - yes, I'm still using it - notified a problem
with a .$$$ scratch file in a directory where I didn't think there should be
a scratch file.
I have 5 databases in 5 sub-directories of D:\DBFiles.
My start-up procedure goes to one of the sub-directories and opens its
database and a form.
(This is my controlling database that contains details of the other 4 DBs
and backups, maintenance, etc., etc..)
The form, basically, has buttons that allow access to the other 4 databases.
The app that is running uses QUIT TO to change to apps that run the other 4
DBs.
Generally, this all works perfectly well - except for the crashes...

Before I removed the scratch setting of C:\TEMP I assumed that all the
scratch files would always be in C:\TEMP.
Having removed it I assumed that the scratch files would be in the
respective directories for each database as and when a database is opened.
CrashGuard had a problem with the .$$$ in D:\DBFiles - not one of the
sub-directories. My short-cut has its start-in directory as D:\DBFiles but a
database is not opened until the app changes directory to one of the
sub-directories. It was set that way originally because I often opened
R:Base to work on apps rather than to _run_ the apps.
If anybody has had any similar experiences or problems with sub-directories
I'd be very interested to hear how they were overcome.
Thanks & regards,
Alastair.
----------------------------------
A D B Burr,
St. Albans, UK.
----------------------------------
[EMAIL PROTECTED]
----------------------------------