Michael: If going to an additional loop is causing problems, you may want to check the "FILES = XX" setting; I routinely set up mine to 50 and I have not had many problems of this type. On new installation, sometimes when I forgot to change this value, I started to have problem on multi-nested programs, changing the setting for files normally took care of this. Javier,
Javier Valencia, PE President Valencia Technology Group, L.L.C. 14315 S. Twilight Ln, Suite #14 Olathe, Kansas 66962-4578 Office (913)829-0888 Fax (913)649-2904 Cell (913)915-3137 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Michael Moser Sent: Tuesday, August 19, 2003 5:00 PM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: The impossible seems to happen RESOLVED Thanks to everyone for all the tips and pointers. Turns out that Troy was right from the start. Once the variables started being mis-evaluated it happend all the time until R:Base was restarted. This gave the illusion that I could check a specific record to see the problem. This file was being run from a while loop in another program. This was the 5th copy of the programming structure, modified for slightly different purposes. None of the previous programs had had a problem but this one had an additional while loop inside it. Cutting out the third level while loop made the problem go away. Replacing the outside loop with a "if-then goto label" structure resolved the problem. In 14 years using R:Base I had never seen a situation where Var1= 'A', Var2 = 'A' and then have R:Base say on the next line that Var1 <> Var2. It made my head spin .... THANKS Troy, I would have never thought to look there. Warmest regards, Michael Michael Moser EXAQ Micro Services Phone: 916-768-7656 Fax: 916-966-8313 >> oops I forgot the "." on the front of vcomp_text. Should read .vcomp_text >> in both places >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Troy >> Sosamon >> Sent: Monday, August 18, 2003 10:50 AM >> To: RBASE-L Mailing List >> Subject: [RBASE-L] - RE: The impossible seems to happen >> Michael, >> If it is that consistent to happen on the same row every time, it is >> probably not related to the while loop, but related to the data. >> I would look at the functions and the data types that you are using. >> I had a cursor that receintly stopped working when the select portion of >> the >> declare had a data type mismatch, but the select by itself worked fine. >> It >> was something like this: >> select * from table1 where company = vcomp_text >> where company was an integer and the var vcomp_text was text. This select >> works fine, but this fails w/o out any explination: >> declare c1 cur for select * from table1 where company = vcomp_text >> My point is that maybee you have a var that is getting declared >> dynamically >> that you are using in a function and it is not the type you are expecting >> it >> to be. >> Troy >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Michael >> Moser >> Sent: Monday, August 18, 2003 10:19 AM >> To: RBASE-L Mailing List >> Subject: [RBASE-L] - RE: The impossible seems to happen >> Hi Troy, >> I thought it might be a memory issue but it seems to be data. It will >> happen on the first loop if I restrict the pointer to a record that causes >> the problem but I can not determine why the same variable condition with >> data from that record will evaluate as False at one point and True a few >> lines later ... can memory leak show up on the second pass of a while >> loop? >> I will try switching to a go to and let you know ... at this point I will >> try anything ... >> :-} >> Thanks for the tip, >> Michael Moser >> EXAQ Micro Services >> Phone: 916-768-7656 >> Fax: 916-966-8313 >> >> This is probably a memory leak issue related to a while loop. >> >> Try changing your while loop into an IF statement and a GOTO. >> >> Troy >> >> -----Original Message----- >> >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of >> Michael >> >> Moser >> >> Sent: Monday, August 18, 2003 9:46 AM >> >> To: RBASE-L Mailing List >> >> Subject: [RBASE-L] - The impossible seems to happen >> >> Hi all, >> >> Here is a mystery that I have been beating my head against a wall >> with. >> >> This code processes about 8,000 records just fine then, with about >> 2,000 >> >> records to go, goes into a infinite loop where variables have to have >> the >> >> same value but do not. if I reverse the sort order, the problem >> happens >> >> after about 300 records. >> >> P800, 512MB Ram, Windows XP Pro, R:Base 6.5++ 1.864xRT03. >> >> Suddenly the second while loop starts evaluating as False, even >> though >> the >> >> values are being set immediately above it to insure a True >> evaluation. >> I >> >> have even inserted diagnostic code to check the length (SLEN) of the >> >> values >> >> which has shown that the variables do contain the same text >> information >> of >> >> the same length but they are being evaluated as different. In one >> >> variation >> >> of the diagnostics I checked all three values in an IF statement, if >> one >> >> was >> >> false I checked each one individually to determine which one. The >> check >> >> of >> >> the 3 indicated that 1 was false, the individual check found all to >> be >> >> True >> >> ... go figure. >> >> Any Ideas? >> >> Thanks, >> >> Michael >> >> Michael Moser >> >> EXAQ Micro Services >> >> Phone: 916-768-7656 >> >> Fax: 916-966-8313 >> >> (Note: the quotes change allows me to insert a text value for "Id" >> using >> >> the >> >> 'text' format.) >> >> SET QUOTES=" >> >> SET V WhereClause = + >> >> ("Where id IS NOT NULL and Qty < 0 and SvcCode <> 10") >> >> SET QUOTES=' >> >> DECLARE PTR1 CURSOR FOR SELECT + >> >> Id,tDate,SvcCode,SvcDesc,Qty,SvcPr,SvcTot,SCS,Paid,tDOE + >> >> FROM Transactions ORDER BY SCS=A, id, SvcCode &WhereClause >> >> OPEN PTR1 >> >> SET V LastId TEXT = 'NONE' >> >> FETCH PTR1 INTO + >> >> oscId X1, osctDate X1, oscSvcCode X1, oscSvcDesc X1, oscQty X1, + >> >> oscSvcPr X1, oscSvcTot X1, oscSCS X1, oscPaid X1, osctDOE X1 >> >> IF SQLCODE <> 100 THEN >> >> SET V LoopStatus = 'RUN' >> >> ELSE >> >> SET V LoopStatus = 'STOP' >> >> ENDIF >> >> WHILE LoopStatus <> 'STOP' THEN >> >> IF oscId = .LastId AND oscSCS = .LastSCS AND LoopStatus = 'RUN' THEN >> >> -- this should NEVER happen but it does. >> >> write 'error 1' >> >> ENDIF >> >> -- ... more code here >> >> SET V LastSCS TEXT = .oscSCS >> >> SET V LastId = .oscId >> >> WHILE oscId = .LastId AND oscSCS = .LastSCS AND LoopStatus = 'RUN' >> THEN >> >> -- ... more code here >> >> FETCH PTR1 INTO + >> >> oscId X1, osctDate X1, oscSvcCode X1, oscSvcDesc X1, oscQty X1, + >> >> oscSvcPr X1, oscSvcTot X1, oscSCS X1, oscPaid X1, osctDOE X1 >> >> IF SQLCODE <> 100 THEN >> >> SET V LoopStatus = 'RUN' >> >> ELSE >> >> SET V LoopStatus = 'STOP' >> >> ENDIF >> >> IF oscId <> .LastId OR oscSCS <> .LastSCS OR LoopStatus <> 'RUN' THEN >> >> write 'message 1, ok to exit exit loop' >> >> ENDIF >> >> ENDWHILE >> >> ENDWHILE >> >> DROP CURSOR PTR1 >> >> RETURN
