Hi everyone..

Discovered a strange anomoly yesterday:

Do a plain-vanilla R/LIST Select : RLIST('SELECT SOMEFILE WITH…BY..',5,,,) @RECCOUNT=143 L0: READNEXT @ID THEN READ @RECORD FROM FILE_IN,@ID THEN .. DO SOME PROCESSING END ELSE .. HANDLE THE READ ERROR END END ELSE … END OF JOB LOGIC END About 50% of the time, the output set contains from 1-4 null records delimited by CR/LF, but no data. Put a test in the code for a null @RECORD or null @ID. Sure enuf it happens. Change the variables from @ID and @RECORD and everything's hunky dory. so the code looks like: READNEXT ID THEN @ID=ID ;* so braces calls will work later READ @RECORD FROM FILE_IN,ID then @RECORD=RECORD ;* so {calls will work later} ..etc. Problem goes away and the @vars are properly set. Any ideas why the original using only @vars doesn't work reliably? Puzzled… Don Miller C3 Inc. </QUOTE> —- === At 02 MAY 2001 04:57PM Robert Lee wrote: === <QUOTE>Hi Don I have tried to duplicate your problem on two of our tables running it through about 10 times each and to no avail. Can you duplicate your problem on another table? I don't suppose a CLEARSELECT at the start of the program will make the problem go away? Does the problem still occur with variations of the WITH statement (eg no WITH, WITH based on a symbolic, WITH based on a data field) </QUOTE> —- === At 03 MAY 2001 09:11AM Don Miller - C3 Inc. wrote: === <QUOTE>Robert .. Yes, the same problem occurs on at least two tables. What is so strange is that if you use a local variable and then assign it to a global variable there is no problem. Eg: READNEXT ID THEN @ID=ID READ RECORD FROM FILE_IN,ID THEN @RECORD=RECORD … no problems at all but if you use '@' variables then it will miss about 10% of the records (but not the same ones). The SELECT statements run from SELECT FILE_NAME BY @ID to SELECT FILE_NAME WITH CLAUSE BY CLAUSE to allow for selective processing and export. There are no symbolics in either the WITH CLAUSE or the BY CLAUSE .. just real fields. The RLIST call is: RLIST(CMD,5,,,) where CMD is the SELECT sentence

Other programs using similar logic don't seem to be a problem. In the head of the program I tried inserting a CLEARSELECT and ahead of each READNEXT in the loop I inserted a FLUSH / GARBAGECOLLECT statement. Makes no difference at all. The same program run in AREV 3.12 has worked flawlessly for years (which is where it came from in the first place). This is OI 3.7 and has been stable as can be for over a year.

My concern is whether there is a hidden "gotcha" somewhere that I just can't find. Very puzzling

Don Miller

C3 Inc.

In coding S/List we found this WAS a problem with calling Yield() so we always saved off the @Vars before a Yield OR a program is likely to call Yield.

The Sprezzatura Group

World Leaders in all things RevSoft

What a smart bunch..

The MSG function with GY option (Gasbar w/YIELD) is the culprit. This was used before the process loop to initialize the counters and image and during processing to update the gasbar & check for cancel button. Saving the @vars before and restoring after the MSG call fixed the problem. This is a definite GOTCHA which should be widely publicized since I bet that a lot of developers use progress bars during batch processing …..

Thanks .. whoever remembered this one …

Don Miller

C3 Inc.

As is frequently the case this was a group effort and as ever de nada .

The Sprezzatura Group

World Leaders in all things RevSoft

Is there any reason why you use GY instead of GC?

I had never heard of the GY option, so I did a search and still can't find anything on it.

Robert:

From MSG_EQUATES:

* to display a gauge (percent bar), use the "G" type

* sub-types are C (show cancel button) and Y (yield on each cycle)

*

I was interested in not hogging the CPU while MSG was executing .. hence the Yield choice. In the Works section, Mike Ruane observed that it is not MSG that causes the problem but $RUN_EVENT. Maybe it will get fixed next release. Meanwhile, check your code that uses Yield() either directly or indirectly when using a resolved select list.

Don Miller

C3 Inc.

View this thread on the forum...