HI Adrian I do not think that is it, I have Delete Dups twice in the code and then I run a command block that does a Select looking for Dups then pulls the rows up in a Form so they can be deleted if needed.
It seems like the computer is skipping like old records use to do and the Insert daily to Hist got 90% done and ran again. The more I think about how this could happen the more mixed up I get, nothing makes sense. All I know is the code works 99.999% of the time and these once in a blue moon things have to be hardware related but if I can find a way to catch this in my code that would be great. Thanks marc ----- Original Message ----- From: Adrian Huessy To: RBASE-L Mailing List Sent: Tuesday, February 26, 2008 9:11 AM Subject: [RBASE-L] - RE: How can make this code better ? Marc I suppose it's the problem of DELETE DUPLICATES which is not removing every double line (perhaps Null-values?). Do you have the chance to change DELETE DUPLICATES to check some unique rows like DELETE DUPLICATES FROM tran_daily USING custnum, date, modf4 ? Regards Adrian ------------------------------------------------------------------------------ From: Marc [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 3:38 PM To: [email protected] Subject: [RBASE-L] - How can make this code better ? Hi Out of 100 offices this has happened only about 6 times in a year. I think it is from computer hiccups but I am wanting to make my code as tight as possible. Basically we put charges and payments in a Tran_daily file. At the end of the day if everything is correct we Close the day, do some updates, move the charges and payments to the Tran_Hist table and summaries the totals in a Recap table with the date on it, then delete the Tran_daily rows. About 90% of the rows from the Tran_daily table got copied (inserted) into the Tran_Hist table twice for 2/8/08. This office has used my app for 10 years and this is the first time it has happened to them. I told them if the same code works 99% of the time and one day screws up it is not the code/RBase it is a computer quirk. Below is a summary of the code, is there a better way to do this or trap for errors? Sorry this is so long Marc DELETE DUPLICATES FROM tran_daily --so this should have stopped the dups in the Hist SET VAR vdaycnt INTEGER = NULL SELECT COUNT (*) INTO vdaycnt FROM tran_daily SET VAR vhistcnt INTEGER = NULL SELECT COUNT (*) INTO vhistcnt FROM tran_hist -- copy tran_daily TO tran_hist INSERT + INTO tran_hist (custnum,date ......... + ................,modf4 FROM tran_daily SET VAR vhistcnte INTEGER = NULL SELECT COUNT (*) INTO vhistcnte FROM tran_hist IF vhistcnte <> (.vdaycnt + .vhistcnt) THEN PAUSE 1 USING 'Some data was not copied to the History file ' ENDIF if this poped up they didn't remember it *(insert RECAP FILE WITH TOTALS FOR DAY) INSERT INTO recap (............ , tptpay,+ VALUES (.vdate, ................ '1',.vtvisa) DELETE ROWS FROM tran_daily SET VAR vrecapchar CURRENCY = 0.00 SET VAR vrecappay CURRENCY = 0.00 SET VAR vrecapchar CURRENCY = tcharges IN recap WHERE COUNT = LAST SET VAR vrecappay CURRENCY = tpayment IN recap WHERE COUNT = LAST IF tcharge = .vrecapchar AND totpay = .vrecappay THEN PAUSE 1 USING 'Finished Recap Created' ICON confirm .... ELSE PAUSE 1 USING + 'Recap DID NOT match Check the Recap and use a Backup if necessary' + ICON SERIOUS BUTTON 'OK' OPTION BACK_COLOR 65535 | ...+ if this poped up they didn't remember it ENDIF RECALC VARIABLES RETURN
