Hi Pawel, I know from previous posts that this is T24 related.
You don't state which T24 release or on which table you are doing the select or even if this is Temenos core code or your own local code. The reason why this may be significant is as follows: 1. SSELECT on SECURITY related tables can cause a problem. I have seen such on SECURITY.POSITION. It occurs because the dictionary says that the ID is right justified in 35 spaces and all of the keys take up 35 characters and you run out of memory. Changing the dictionary to left justified solves the problem. 2. If this is local dev, then doing an internal select can be much faster. Where you expect to retrieve more than 50% of the keys and the condition is based on the key, then an internal select with code will be much faster and not hog the memory. 3. In local dev, many people try to do all of the processing in one job when it would be more performant to select in one agent process and process the keys in another. As an addendum to this, if you do humongous processing in a job with transaction turned on all sorts of memory issues occur. 4. The selection operation used by EB.READLIST has changed in later releases (R6 or maybe R7) where internal select is used if the select statement is called without parameters 5. I believe that SSELECT can be called as an internal selection rather than an external selection which means that all of the keys are not require to be stored before they can be processed/ Hope this is of interest Mike --~--~---------~--~----~------------~-------~--~----~ Please read the posting guidelines at: http://groups.google.com/group/jBASE/web/Posting%20Guidelines IMPORTANT: Type T24: at the start of the subject line for questions specific to Globus/T24 To post, send email to [email protected] To unsubscribe, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jBASE?hl=en -~----------~----~----~----~------~----~------~--~---
