That's good advice. I was just showing you what happens if you change it after connecting and the fact that you Can. You just have to be aware of the results. Notably, RBase "remembers" the scratch location even if you change it until the next disconnect....
----- Original Message ----- From: "William Cook" <[EMAIL PROTECTED]> To: "RBASE-L Mailing List" <[EMAIL PROTECTED]> Sent: Tuesday, February 11, 2003 11:12 AM Subject: [RBASE-L] - Re: Runtime prob with "set scratch" > But were we not told just recently that the SET SCRATCH should be > before CONNECTing? > > ----- Original Message ----- > From: "MikeB" <[EMAIL PROTECTED]> > To: "RBASE-L Mailing List" <[EMAIL PROTECTED]> > Sent: Tuesday, February 11, 2003 7:51 AM > Subject: [RBASE-L] - Re: Runtime prob with "set scratch" > > > I can change the Scratch settings connected or not, however any > scratch > files created, are created in the directory that is used AFTER the > first > scratch files are created. For Example: > > Connect DBname > set Scratch d:\temp\ > proj temp tTable from SomeTable using * > -- The tTable is created in d:\temp\ > set Scratch f:\temp\ > proj temp tTable2 from SomeTable using * > -- The tTable2 is created in d:\temp\ > disco > Connect DBname > proj temp tTable from SomeTable using * > -- The tTable is created in f:\temp\ > > > > > > > ----- Original Message ----- > From: "William Cook" <[EMAIL PROTECTED]> > To: "RBASE-L Mailing List" <[EMAIL PROTECTED]> > Sent: Tuesday, February 11, 2003 10:13 AM > Subject: [RBASE-L] - Re: Runtime prob with "set scratch" > > > > Ben, > > > > We have been told that the SET SCRATCH must occur before connecting. > I > > have a note that startup may involve three pieces of code: > > 1. the startup file in RBASE.CFG > > 2. the file mentioned on the command line > > 3. RBASE.DAT > > > > Is it possible one of these causes a connect prior to your SET > > SCRATCH? > > (and perhaps trying to use a folder for which you lack write access) > > > > Bill Cook > > Kent WA USA > > > > ----- Original Message ----- > > From: "Ben Petersen" <[EMAIL PROTECTED]> > > To: "RBASE-L Mailing List" <[EMAIL PROTECTED]> > > Sent: Monday, February 10, 2003 11:09 PM > > Subject: [RBASE-L] - Re: Runtime prob with "set scratch" > > > > > > Thanks JM, > > > > I have moved set scratch to the beginning of rbase.dat just as you > > have it, but it made no difference. > > > > While a nice feature, I don't think it is required for RBase to > create > > temporary files. > > > > I _have_ discovered that what I thought was looping was caused by > > a missing piece of data. So I only need to understand why I'm > > getting the "Can't create temporary files" error when the app first > > starts. What causes RBase to exit the app before the first menu > > when scratch _is_ set isn't really important, I guess. > > > > Ben Petersen > > > > > > On 11 Feb 2003, at 9:09, J.M. GRATIAS wrote: > > > > > > > > Ben : > > > > > > >> > > > If I set scratch specifically the app will not get as far as the > > first > > > menu. Also; with scratch set to C:\windows\temp, RBase will leave > a > > > $$$ file behind, but always 0 bytes in size. If I don't set > scratch > > > specifically, I get the error "Can't create temporary file (2964)" > > > but the app starts. "Sho Scratch" says scratch files will placed > in > > > the database directory. .... << > > > > > > I noticed that : > > > > > > - SET SCRATCH must be set immediatly when entering the app, and > > before > > > connecting the DB, I use to do that in RBASE.DAT : > > > > > > -- RBASE.DAT > > > CLEAR ALL VAR > > > DISCONNECT > > > SET STATICDB OFF > > > -- Indiquer ci-apr�s le r�pertoire des fichiers temporaires > > > -- Choisir de pr�f�rence un disque local rapide > > > SET SCRATCH 'D:\rbw65\temp' > > > ..... > > > > > > - whatever scratch is set to, there are some (few) $$$ files that > > can > > > stay in the current directory when RBW/app don't exit correctly. > > This > > > is true when running every RBW version until 1.851 I did't check > > with > > > the laterst versions. > > > > > > Hope this will help .... > > > > > > J.M. GRATIAS, Logimatique > > > > > > > > > > > >
