Thanks for all the suggestions. To take the points raised: R:Base is 6.5++p3 - ie: the latest beta running under W98SE.
I, too, have been suspicious of CrashGuard but this app crashes with or without it and, generally, when R:Base crashes it is sometime possible to re-start it when CrashGuard is running. It has to be said that the Dos version I ran before changing to the Windows version of R:Base rarely crashed but it seems as if I am now lucky if I get through any R:Base session without some form of crash. Obviously is the syntax is wrong then I expect a problem and an error message but this goes through trace without any. For what it's worth since I last cleared the statistics from the CrashGuard log - around mid-July last year - there have been 517 crashes on my system, 219 by rbg65.exe, 8 by gd132.dll, 67 unknown & 19 by kernel32.dll that are related to R:Base - a total of 365. The next most frequent is WinWord with 37 altogether then all in single figures. Before anybody asks, I have re-installed R:Base from the CD just prior to applying the first patch and again just before the second patch was added. To be fair, the majority of these crashes come in groups when something like this happens and I try repeatedly to resolve a problem Is the error code always the same (Access violation C0000005) ? Not exclusively, but certainly the most frequent by a long way and going back to July last year when I changed to RBW. As Bob Thompson has similar problems with RHIDE does anybody else as well? I thought that this feature was meant to hide the background screen not make it inaccessible unless the RSHOW command is run. Any error/crash between the two is a problem. Yes, I have done the reload and autochk. I have autochk set to run whenever I go to the R:> via a command file before I do any work an a database and reload is second nature with any known problem. Neither show any clues. Although it's a lot of work, I think I am going to re-create the database from scratch. There is not much data in it and that is easy to export and then import into a new copy. The creation of the form is what will take the time. Regards, Alastair. ----- Original Message ----- From: "Alastair Burr" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 05, 2002 11:29 AM Subject: Re: Persistant System Crashes but TRACE reports no errors - Razzak's Reply > Thanks Razzak for your swift response. > > However, there are _no_ while loops in the app. All it does is gather some > info from one database and create a temp table with that data in the driving > database for use in a form for display purposes. The form does not get > updated as it has a number of buttons which run other apps. It has only > started crashing since adding the temp table with the displayed data to the > form. > > I thought that it might be the latest beta version so I reverted to patch 2 > but that made no difference - as expected, really. I have also checked that > all the variables are pre-defined, not deleted, nor data type changed before > the form is run with edit using. > > I have found something that seems to make a difference in that I get crashes > only 50% of the time now. Running the app immediately after booting now > seems to work but second or subsequent attempts cause a crash. Those > subsequent attempts seem to fail because RBG65 is still running according to > Windows after a crash. I suspect that the HIDE command is a problem here > because the crash happens before the SHOW command is reached. However, > removing the HIDE & SHOW commands does not stop the crashing. As far as I > can see the EXIT command is run properly but maybe the form does not close > correctly. I'm clutching at straws here. > > What I have changed is this: > > CREATE TEMP TABLE ToDo (Things TEXT (60), EntryDate DATETIME) > > to: > > CREATE TEMP TABLE `ToDo` + > (`Things` TEXT (60), + > `EntryDate` DATETIME ) > > ie: added the IDQuotes around the table and column names. > If this is a syntax error then trace does not seem to pick it up, nor does > it appear to matter from the R:> when creating the table "manually". It > might be part of the problem when creating the table via the app. > > What I might be able to do is to reconfigure the form to use only the temp > table or use the temp table as the driving table and see if that makes any > difference but that seems to be avoiding the problem rather than resolving > it - even if it were to work... > > Any further suggestions gratefully accepted, > Regards, > Alastair. > > > ----- Original Message ----- > From: "A. Razzak Memon" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, June 05, 2002 1:14 AM > Subject: Re: Persistant System Crashes but TRACE reports no errors - > Razzak's Reply > > > > > > At 12:19 AM 6/5/2002 +0100, Alastair Burr wrote: > > > > >Can anyone tell me how it is possible to run an application through TRACE > > >and consistently have no errors and yet R:Base crashes EVERY time I start > > >the app via an icon? > > > > > > Alastair, > > > > Looks like the WHILE loop optimization issue! > > > > SET WHILEOPT OFF at the mighty R> prompt and try it again. If it runs > > then you know there is a problem with an optimized command and the > > problem is most likely with a variable used in that command. > > > > FYI, TRACE does not use the WHILE loop optimization. > > > > WHILE loops were always considered one of the faster ways to process > > code because R:BASE read the WHILE loop code into memory and parsed > > it before beginning execution. R:BASE did not need to do line-by-line > reading > > and parsing of the code for each iteration of the WHILE loop. As it is > read > > into > > memory the WHILE loop code was parsed in tokens (4-byte segments). But > > R:BASE still needed to figure out what was what -- parse the expressions, > > find variable names and values etc. It was faster than reading and parsing > > line-by-line, but not as fast as it could be. > > > > Tips: > > > > 01. Datatype variables at the beginning of a command file or before the > > WHILE loop is executed. Don't datatype variables inside the WHILE > > loop, they won't be optimized. > > > > 02. The variables used in any optimized command can change values as > > the WHILE loop iterations are executed, but they cannot change data > > types and cannot be cleared (with the CLEAR VAR command). > > > > 03. The value can be reset to NULL (SET VAR vname = NULL) but not > > cleared. > > > > 04. If you determine that the problem is with an optimized command, review > > the rules above, you may be clearing, retyping or not data typing a > > variable. > > > > Well, that should give you pretty good idea. > > > > Very Best Regards, > > > > Razzak. > > > > P.S. After the Inside R:BASE 7.0 for Windows training session this week, > > I'll post more details at: htp://www.razzak.com/fte > > > > > > > > ================================================ > > TO SEE MESSAGE POSTING GUIDELINES: > > Send a plain text email to [EMAIL PROTECTED] > > In the message body, put just two words: INTRO rbase-l > > ================================================ > > TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] > > In the message body, put just two words: UNSUBSCRIBE rbase-l > > ================================================ > > TO SEARCH ARCHIVES: > > http://www.mail-archive.com/rbase-l%40sonetmail.com/ > > ================================================ > TO SEE MESSAGE POSTING GUIDELINES: > Send a plain text email to [EMAIL PROTECTED] > In the message body, put just two words: INTRO rbase-l > ================================================ > TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] > In the message body, put just two words: UNSUBSCRIBE rbase-l > ================================================ > TO SEARCH ARCHIVES: > http://www.mail-archive.com/rbase-l%40sonetmail.com/ ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l ================================================ TO SEARCH ARCHIVES: http://www.mail-archive.com/rbase-l%40sonetmail.com/
