I had a look at the SELECTS and have managed to identify the code that
causes the program. I have modified this and it now works fine.
However, I'm curious why the code would cause a problem.
Here is some code which causes the user memory to go up. The only way
we get the memory back is by logging out of Universe so please be
careful if you run this.
============================================
FILENAME = "TEST.FILE" ;* TEST.FILE in our case had 4500 items in with
multivalued date in attribute 1
*
LOOP
LIST.VAR = ""; LIST.VAR2 = ""
EXECUTE 'SELECT ':FILENAME CAPTURING JUNK RTNLIST LIST.VAR SETTING
TOTAL
IF TOTAL THEN
EXECUTE 'QSELECT ':FILENAME:' (1' CAPTURING JUNK PASSLIST
LIST.VAR RTNLIST LIST.VAR2 SETTING TOTAL2
END
* The program then used TOTAL2 to do subsequent processing
INPUTIF JUNK THEN EXIT ;* quit loop once user presses a key
REPEAT
============================================
The fix which works fine is as follows
LOOP
LIST.VAR = ""
EXECUTE 'SELECT ':FILENAME:' SAVING 1' CAPTURING JUNK RTNLIST
LIST.VAR2 SETTING TOTAL2
* this generates the same number as the previous select but does not
effect the memory
INPUTIF JUNK THEN EXIT ;* quit loop
REPEAT
============================================
Cheers
Matt
acollazo (AT) tsbrass (DOT) com (Angelo Collazo) wrote in message news:<cfb4de4e.0310290648.12162310 (AT) posting (DOT) google.com>...
Quote:
Can you paste the proc(s)/program(s)that are causing this issue?, You
need to make sure that each select is assigned a number(select file to
OUT1, select file to OUT2).
Angelo,
Lambrecht <member45678 (AT) dbforums (DOT) com> wrote
Hello,
If you find in the DICT of the file the @KEY item, delete it or verify
it
(The @KEY is an undocumented feature that may by a D-type, an I-
type or a PH)
Henri Lambrecht |