Hi Randy - please see my comments below yours...
----- Original Message ----- From: "randyp" <[EMAIL PROTECTED]> To: "RBASE-L Mailing List" <[EMAIL PROTECTED]> Sent: Monday, December 30, 2002 3:30 AM Subject: [RBASE-L] - Criteria For My Unstableness With R:Base6.5++ Build 1.862 > Alastair, > > Another 'hidden' place to check is forms. It is > possible to create a variable such as VNumber INTEGER and > place the variable on a form. Later you determine you would > rather change the variable type to TEXT. You change the > variable in all your code. Everything is fine until the > form opens and the form re-types the variable back to > INTEGER, as it was when the variable was placed on the form. I really had nothing better to do today <g> than check all my forms. But, seriously, you're right and although I don't think I've got any errors of that sort I'll double check. Generally speaking, I tend to use suffixes "_Int" or "_Txt" for those variables that might be subject to mis-typing or where I need to change the type for some reason. > In order to have the variable typed properly, you > have to delete the variable. Then put the variable back on > the form while it is the correct type. I have a command file that is called whenever I start R:Base - even just to go to the R:> - that sets up any temp tables that forms are based on and any variables that are needed. In theory, this gets updated whenever I make a change that is intended to be permanent (but not for ad hoc queries and while testing). Like the forms, I'll double check it. > I can't remember whether columns automatically > change on a form to the new data type, or whether this > process must also be used for columns after changing data > type. I thought that forms and reports got changed automatically but you _have_ to open each one and make some sort of change and save it for the update to take effect. > Once I started clearing, and pre-defining all form > variables to null or whatever in the code just prior to > opening a form I stopped having these kind of crashes. If I ever finish all these checks <g> I'll be able to use R:Base and find out if the number of crashes has decreased! Again generally speaking, I set all my variables to null at the top of the command file and then give them any pre-determined value later on. Two reasons: firstly to try to avoid errors but, just as importantly, so that I can easily see what is already defined and avoid re-using or re-typing by mistake. eg: SET VAR vID_Txt TEXT = NULL SET VAR vID_Int INTEGER = NULL -- do stuff SET VAR vID_Int = 12345 SET VAR vID_Txt = (CTXT(.vID_Int)) > Randy Peterson > > PS. Using TRACE should show you the specific command which > is not being interpreted successfully. You can use that > same command from the R:Prompt, or check the values of > variables and system settings to continue to approach the > cause of the difficulty. I often paste commands that trace chokes over to the R:> and work on them there until I have the syntax - and my conditions - right. Indeed, that was what I was doing yesterday when my mdi form was not sorting the sub-table correctly. Luckily the cause of those crashes was obvious but I can't believe that simply getting the syntax wrong should have that effect. > I religiously use R:Code. Yes, my marathon yesterday converted me. Can anybody confirm that it is up-to-date with the latest patch? I can not see any (obvious) RCode file that matches the dates of the recent patch. Most files are dated 15/05/2001; rcode.fts is dated 22/06/2002 & rcode.gid is dated 29/12/2002. RStyle has similar file dates. Regards, Alastair.
