Ben: I recently had a problem that kept crashing the system, I checked, traced and verified every way that I could think of without luck. I finally sent a copy of the data base and application code to RBTI and they figure out that the problem was caused by a jpeg file (blob) displayed on the opening screen that was causing the problem way down the code, they suggested a workaround that seems to be working. I still do not know exactly why it happened but I am sure glad that my problem was solved, overall I am pleased with the latest release; once you get the kinks worked out (and herein lies the problem) it works pretty solidly. I am hopping to switch to 7.0 as soon as feasible. As a developer, sometime I get extremely frustrated (as my receding hairline will attest) when I run into problems for which there is no apparent cause and spend hours and hours trying to find a solution and/or workaround. My experience is that 9 out of 10 times, it is indeed a problem with code brought out by stricter enforcement of syntax by new releases, the rest of the time I have submitted to RBTI and so far they have been able to help every time (touch wood!!!) Because of these problems, I have adopted some quick rules on all new code or when I re-write existing code (in addition to the ones I posted before): Keep lines short, sometimes long lines will exceed the limits of the interpreter/compiler and it will be difficult to debug as the syntax appears correct, but in fact R:Base is not seeing the entire command line. RStyle will show the limit line, but if I remember correctly, it will not call it an error. I use the entire command name (no abbreviations) as it prevents confusion when the short name for new commands may conflict with an old/existing ones. I use upper case for all R:Base commands in the code, it helps a great deal when debugging. RStyle is very good at finding unbalance parentheses, quotes, commas, etc. Use only one rbase.cfg file as the settings saved in a different file can create problems; this is the first thing I check when an application will work in one computer but not on another, many times I found that a different rbase.cfg in the path was creating problems. Program defensively, account for all the keystrokes that users may use, i.e. [ESC]. Do not hesitate to post the issue to the list, I have found problems I did not know I had until I saw someone else's post and checked my own code. And finally, the golden rules of programming: "The user never knows what he wants and seldom knows what he needs" and my all time favorite: "You cannot have a foolproof system because fools are too smart" I realize that the "golden rules" do not directly apply to the issue at hand; however, sometimes they help keep things in perspective...
Javier Valencia, PE President Valencia Technology Group, L.L.C. 14315 S. Twilight Ln., Suite #14 Olathe, KS 66062-4571 (913)829-0888 (913)649-2904 FAX -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ben Petersen Sent: Friday, January 03, 2003 3:46 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Criteria For MyUnstablenessWithR:Base6.5++Build 1.862 Dr R> ttbomk I follow the guidelines you set out below. And my apps run perfectly on my own machine in testing, sometimes requiring a pause for unknown reasons; but leave here working none the less. And, in general, run fine on the majority of my client's systems. It's the exceptions that are the show stoppers. On two occasions I have tracked the problem down to the offending line of code... inserted blank lines above and below, and the problem was solved. This was required for two different clients within two different code segments. Another mystery required calling Hawaii with pcAnywhere over and over (crashing the client's system each time and they restarting) until I came to a block of code that was as simple as pie... could not be the problem, works on a half dozen other computers, but not theirs. I've never resolved it and it doesn't occur anywhere else. For the record, each was tested on my computer using the same apx and database files. I don't believe that RBase is "at fault"... at least not directly as in erroneous code. But maybe something external is not accounted for... anti virus software, a particular driver, the phase of the moon... Allastair's attempt to find commonalities to these boo boos might prove helpful. Ben Petersen On 3 Jan 2003, at 3:51, A. Razzak Memon wrote: > > At 08:26 AM 1/3/2003 +0000, Alastair Burr wrote: > > >In the mean time does anybody else who is having these crashes have > >any of the following conditions: > > > >Is the form that might be the cause one that is based on a temp > >table? Do you have any "set" commands that are database linked but > >with no database connected prior to calling the form? Or maybe ones > >that need the owner password? Do you have any other commands that > >return an error that you believe that you can safely ignore prior to > >calling the form? Disconnect when there is no db connected, for > >example. > > > > Well Alastair. > > I think, you are answering your own questions. And, let me see if I > can help you understand: > > 01. If the form is based on a TEMPORARY TABLE, you, as a > programmer, > need to make sure that the related TEMPORARY table exist > before using the form. > > TEMPORARY TABLES are disappeared when the database is > DISConnected. > > You will need to create startup file to re-define those > temporary > tables. > > 02. Use CVAL('Database')) option to return a text string > containing the current connected database or NULL if > the user is not connected to a database. This can be > used to ensure that the user is connected before > trying to execute some code. The example below shows > how this might work. > > SET VAR vDB = (CVAL('Database')) > IF vDB IS NULL THEN > CONN MyDB > ENDIF > > SET VAR vDB = (CVAL('Database')) > IF vDB IS NULL THEN > PAUSE 2 USING 'MyDB is currently unavailable' > ENDIF > > The check is repeated to ensure that the attempt to > connect to the database was successful before > continuing with the command file. > > 03. Make sure to pre-define all global variables used in forms > with > appropriate data type. > > 04. Use ENTER USING FormName or EDIT USING FormName at > the R> prompt to make sure they work. > > 05. Make sure to SET MESSAGES ON and SET ERROR MESSAGES ON > while testing and debugging your forms, reports, command > files, etc. > > 06. Use TRACE to narrow down the problem, if any, in your code. > > 07. If you are using any bit map buttons on form, make sure to use > BMP. > (works better in 6.5++ for Windows) > > Of course, 7.0 supports ALL kinds of buttons and graphics, > including maps and GPS coordinates. > > Hope that helps! > > Very Best Regards, > > Razzak. >
