Marc,
I agree with you about keeping track of the variables. That's one nicest features of 64 bits version, the limitations in the length of variable name have gone. I have implemented a way of programming in which I make a distinction between local and global variables. For instance: Global variables start with V_ (V underscore) Local variables start with something like VL_ (VL underscore) At the end of each procedure there is the statement: CLEAR VAR VL_* In this way you will keep your application nice and clean regarding to variables. Tony From: [email protected] [mailto:[email protected]] On Behalf Of MDRD Sent: woensdag 4 januari 2012 23:47 To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Win 7 problem Thanks Karen I do use Count(*) in several places but not everywhere, I was trying to avoid setting too many Vars and keeping track of them... Marc From: [email protected] Sent: Wednesday, January 04, 2012 4:40 PM To: RBASE-L Mailing List <mailto:[email protected]> Subject: [RBASE-L] - Re: Win 7 problem I'm with Tony. I never rely on SQLCODE to give me an error condition. I do a count(*) first. I've heard quite a few stories of SQLCODE giving different results based on the computer's operating system. And if my count(*) is based on a large table, I will always add "and limit = 1" to the end of my Select so that it stops counting as soon as it finds one record. Karen In a message dated 1/4/2012 1:41:53 PM Central Standard Time, [email protected] writes: Marc, My way of dealing with this kind of queries is to make use of a COUNT, like: Set var V_Count integer = 0 Select count(*) into V_Count indicator V_Count_ind + from <tableview> + WHERE (cust1 = .vcust1 OR cust2 = .vcust1 OR cust3 = .vcust1 + OR cust4 = .vcust1) AND aptdate >.#DATE If V_Count = 0 then PAUSE 1 USING 'Needs to make an Apt' CAPTION 'No APts set' ENDIF BTW Have you noticed the RETURN after ENDIF. The routine will stop at that point Tony
