As I said, on the NT4 boxes, adherence to the HCL is required for reliability.

----- Original Message ----- 
From: "Alastair Burr" <[EMAIL PROTECTED]>
To: "RBASE-L Mailing List" <[EMAIL PROTECTED]>
Sent: Thursday, July 24, 2003 12:22 PM
Subject: [RBASE-L] - Re: Setting Scratch, scratch files and R:Base crashes


> Thanks, if a number of programs were crashing regularly I'd re-install the
> O/S. But I'm not getting an unacceptable number of crashes from other
> programs - only R:Base. However, since changing the .DAT extension for an
> output & then run file, and removing the srcatch setting even R:Base is
> behaving _much_ more acceptably. This doesn't, to my mind, point to a
> problem with my machine.
> 
> That said, I've got nothing better to do <g> so I'll go through the files
> via the file checker and replace those that I think could be "wrong" - even
> if it means two or three runs through. Presumable the Microsoft on-line
> update utility will then replace any that it thinks are wrong next time it
> does its check.
> 
> If I remember correctly on NT the service pack read-me insisted that a
> re-patch should be done after new software was added but, when I was at
> work, we had NT servers that crashed regularly and often and all they did
> (more or less) was run Lotus Notes. I don't miss them at all!
> 
> Thanks & regards,
> Alastair.
> 
> 
> 
> ----- Original Message ----- 
> From: "MikeB" <[EMAIL PROTECTED]>
> To: "RBASE-L Mailing List" <[EMAIL PROTECTED]>
> Sent: Thursday, July 24, 2003 3:36 PM
> Subject: [RBASE-L] - Re: Setting Scratch, scratch files and R:Base crashes
> 
> 
> > You assume wrong.  The changed files are system files that other software
> has replaced with their
> > own (which may or may not be the same as the original).  That is the
> purpose of this utility.  It's
> > a 'manual' execution of what is automatic in WinXP, to protect and persist
> the files that Windows
> > relies upon for its' own proper execution.  If I had a machine that (after
> ruling out hardware, nic,
> > ram, etc) continually crashed running programs, I would delete the
> partition,  and reinstall the OS
> > to its virgin state and adhere to a practice of protecting the files that
> maintain its installed
> > state.  BTW, Updates are likely security issues and not OS fixes, but
> after you do a virgin install,
> > you can run the utility and then run all Microsoft Updates available, then
> rerun the Utility and
> > "accept" the microsoft files to the approved list, then consider that
> state as the point of
> > beginning.  On my old NT boxes, I always reinstalled the Service Packs
> after installing new
> > software.  I am not kidding when I say the Server Has Never locked up,
> blue screened, and except
> > when there is sever electrical storms(we are outside the city and our Elec
> utility goes down
> > frequently, so I don't risk some snafu during the night and shut down
> occasionally), it never gets
> > rebooted.  The NT development machine during debugging sessions is another
> issue as you would
> > expect, but never during ordinary software execution.
> >
> >
> >
> > ----- Original Message ----- 
> > From: "Alastair Burr" <[EMAIL PROTECTED]>
> > To: "RBASE-L Mailing List" <[EMAIL PROTECTED]>
> > Sent: Thursday, July 24, 2003 1:56 AM
> > Subject: [RBASE-L] - Re: Setting Scratch, scratch files and R:Base crashes
> >
> >
> > > I've done this before and I know that it comes up with a large number of
> > > changed files but I have assumed that because Microsoft automatically
> > > updates and applies patches on-line that it would be unwise to revert
> them
> > > all to the originals.
> > >
> > > Have you any guidance?
> > >
> > > Regards,
> > > Alastair.
> > >
> > >
> > > ----- Original Message ----- 
> > > From: "MikeB" <[EMAIL PROTECTED]>
> > > To: "RBASE-L Mailing List" <[EMAIL PROTECTED]>
> > > Sent: Wednesday, July 23, 2003 8:09 PM
> > > Subject: [RBASE-L] - Re: Setting Scratch, scratch files and R:Base
> crashes
> > >
> > >
> > > > Just for kicks, start win98>Start Button>Programs>Accessories>System
> > > Tools>System Information[starts
> > > > applet]>Tools>System File Checker[starts subapplet].  I would like to
> see
> > > the results.  It may
> > > > "enlighten" you.
> > > >
> > > >
> > > >
> > > > ----- Original Message ----- 
> > > > From: "Alastair Burr" <[EMAIL PROTECTED]>
> > > > To: "RBASE-L Mailing List" <[EMAIL PROTECTED]>
> > > > Sent: Wednesday, July 23, 2003 1:21 PM
> > > > Subject: [RBASE-L] - Re: Setting Scratch, scratch files and R:Base
> crashes
> > > >
> > > >
> > > > > Yes, I know a lot of people have said the same thing but if I remove
> it
> > > I
> > > > > lose data more often than not when R:Base crashes. As I said to
> Mike,
> > > > > usually, I can recover R:Base enough with CrashGuard to save my
> work.
> > > > >
> > > > > The real crux is that R:Base really should not crash - full stop.
> > > > >
> > > > > According the C/G stats: R:Base has crashed 947 time since I last
> reset
> > > the
> > > > > system on 06/06/2002.
> > > > > The next biggest offender is Wordpad with 44 - but I know why that
> > > happens
> > > > > and I can control it.
> > > > > After that, Irfan viewer with 15 - and that usually crashes
> > > because/after
> > > > > R:Base crashes and I can't recover it.
> > > > > Everything else is less than 10.
> > > > >
> > > > > Regards,
> > > > > Alastair.
> > > > >
> > > > >
> > > > >
> > > > > ----- Original Message ----- 
> > > > > From: "David Billing" <[EMAIL PROTECTED]>
> > > > > To: "RBASE-L Mailing List" <[EMAIL PROTECTED]>
> > > > > Sent: Wednesday, July 23, 2003 2:05 PM
> > > > > Subject: [RBASE-L] - Re: Setting Scratch, scratch files and R:Base
> > > crashes
> > > > >
> > > > >
> > > > > > Hi Alaster,
> > > > > >
> > > > > > My experience with "CrashGuard" was similar to Mike's, but I
> started
> > > with
> > > > > > Win98.  I believe even Symantec got the message and doesn't market
> it
> > > any
> > > > > > more.  It didn't come with my new System Works 2003.  I'd get rid
> of
> > > it if
> > > > > I
> > > > > > were you.
> > > > > >
> > > > > > Dave Billing
> > > > > > Tall Tree Business Solutions
> > > > > > ----- Original Message ----- 
> > > > > > From: "MikeB" <[EMAIL PROTECTED]>
> > > > > > To: "RBASE-L Mailing List" <[EMAIL PROTECTED]>
> > > > > > Sent: Tuesday, July 22, 2003 1:56 PM
> > > > > > Subject: [RBASE-L] - Re: Setting Scratch, scratch files and R:Base
> > > crashes
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > I thought "CrashGuard" cause more trouble than any piece of
> utility
> > > > > > software I ever installed.  That
> > > > > > > was early Win95 when I installed it and removed it very shortly
> > > > > > thereafter...
> > > > > > >
> > > > > > >
> > > > > > > ----- Original Message ----- 
> > > > > > > From: "Alastair Burr" <[EMAIL PROTECTED]>
> > > > > > > To: "RBASE-L Mailing List" <[EMAIL PROTECTED]>
> > > > > > > Sent: Tuesday, July 22, 2003 7:16 AM
> > > > > > > Subject: [RBASE-L] - Setting Scratch, scratch files and R:Base
> > > crashes
> > > > > > >
> > > > > > >
> > > > > > > > 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]
> > > > > > > > ----------------------------------
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
> 
> 

Reply via email to