Being a PROCologist, this problem was very popular in the Jurrasic Pick era.
When these processes were handled in proc and the results sent to a databasic program, we could interrogate the errmsg variable E. Thus if you were trying to QSELECT something from a 'No Items Present' QUERY, you would accidentally get everything. By interjecting an IF E = 401 blah, blah construct between the 2, you could detect the failure of the first. The CAPTURING clause of EXECUTE (or other 'status' variables on different systems) could indicate the success/failure. But, sometimes there no room between an EXECUTE and its subordinate DATA statements for such an interrogation. Perhaps consecutive EXECUTES would work. As I straddle many flavors of MV, I tend to program with the lowest common denominator. Given your example and the unlikely chance that your users would type PO.GROUP ABC] or [ABC or [ABC] (open/close square brackets), they are really searching for one PO.GROUP ABC. Your QUERY is burdensome as it requests to search through the entire file lookine for a primary key equal to "ABC". While it finds it eventually, if the square brackets aren't part of the plan, a lot of time is wasted. The QUERY should be QUERY = \SELECT PO.GROUP 'Group Reference'\ without the equal sign. Your 3 statements can be reduced to 2. > QUERY= \QSELECT PO.GROUP '\:Group Reference:\' (2)\ > DATA \SSELECT POF BY GROUP BY-DSND PO.DATE Plus you can speed things up by removing the BY GROUP if there's only 1 group per POF and your users don't use square brackets. I've never experienced a recurring effect from a prior failed process at TCL or in a PROC. If you are getting this recurring value as a subroutine, perhaps something's not cleared etc. If you're using a 4GL with latency issues, ie System Builder or on Unidata, that could be the culprit as well. One final note. Unless user fields are validated upon entry, they could process erroneous requests, ie SELECT EMPLOYEE WITH GENDER = "D". Sometimes on older systems with no field validation in this case, you can teach the smarter users on the use of the square brackets within their answers. I've even taught one user how to imply multiple answers within a single field. If the field was ENTER STATE and the process put double quotes around the answer for the SELECT, this 'super user' could answer with NJ""NY and get both states. Actual mileage may differ. My 3 cents. > I'm having a problem I just can't figure out a solution to. > > Got a 'home made' index file with record key being a purchase order 'group > reference#' and the 2nd attribute contains an mv array of all purchase order > numbers > > Am working on writing a 'lookup' subroutine that will utilize this index file. > > Using commands like: > > QUERY = \SELECT PO.GROUP = 'Group Reference'\ > DATA \QSELECT PO.GROUP (2)\ > DATA \SSELECT POF BY GROUP BY-DSND PO.DATE\ > > EXECUTE QUERY > > Well, this works absolutely fine as long as the user enters in a group > reference# that exists. > > BUT, from the first subroutine call where a user enters a group reference# that > does not exist the lookup subroutine fails from that point on to return any > results even if the user subsequently enters an existing group reference#. > > I hope I explained this properly. Bottom line is - the subroutine fails forever > to return any results after the first instance where a user keys in a ref# that > does not exist even when they retry with a valid ref#. > > I just don't get it. I would expect that if a user keys in a ref# that doesn't > exist the query in the subroutine merely returns no records keys - of course - > but if it is called again with a ref# that does exist I would fully expect it to > return results as it does 'the first time' it is called and an existing ref# is > entered. > > joe > > Joe Walter > > "Live dangerously - Communicate!" > > 8..7 4(()) -:&:- > -:&:- 8.74 .74(()) > ((88.74 ..74 -:&:- > ((88.74 * > ------- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
