Select Problem from window subroutine (AREV Specific)
At 19 APR 1998 07:36:31AM A. Singer wrote:
From a window a post-prompt subroutine calls calls a Perform Selct Command. The select command looks whether the table connected to the window already contains rows with certain information or not. What the select command is looking for depends on what the user types in.
What happens is that even if no row is found in the selection process @record after the selection process does not contain the original data the user typed in but the data of one of the rows which are already in the table. There is no selection process before. The select command itself is as I can see from the command stack correct. From writing @record to another table I know that the contents of @record is correct before the select command is called and that it is wrong after the selection process is finished.
Does anybody have any explnation or even know how to work around this?
A similar problem I get in another application when I use a RBASIC select in combination with reduce.
Thank you very much to all who take the time to help!
At 19 APR 1998 07:48AM Egbert Poell wrote:
@Record is made available to the new SELECT-proces that you start.
You should save the contents of @Record to a variable or a reccord in a file en put it back afterwards.
Variables like @Record, @Pseudo, @Id etc. are filled by AREV -processes very often.
Saving them and putting them back afterwards is the solution if you want to work this way.
Succes
Egbert Poell
Mecomp Automatisering
At 19 APR 1998 09:42AM A. Singer wrote:
Hallo Egbert,
thank you very much for your advice. At the moment it works.
However your comments rise some additional questions:
From where do I know, which AREV variables like @record are used by which command in which way?
It would have been logical if a row which fulfills the search criteria would appear in @record or at least its key in @id. However why does any row, which does not fulfill the search criteria, appear in @record?
You mentioned that storing in another variable would be the solution if I wanted to work in this way. Well I did not use a multipart key because the contents of two of the fields consists of information longer than 50 characters. Two other fields contain dates. I think that such fields are unappropriate keys.
Thank you very much!
With kind regards
A. Singer
At 20 APR 1998 03:31AM Andrew P McAuley wrote:
Normally your variables are safe BUT if you use a PERFORM you are saying to the system that you want to share certain variables between levels so that the results may be returned. If you don't want to lose your @Record @Dict etc etc then you should do the following
Call Push.Session(Cursor, Sent, Rec, Id, Dict, MvStuff)Perform MySentenceCall Pop.Session(Cursor, Sent, Rec, Id, Dict, MvStuff)Note that an Execute behaves differently but will not return an active select list.
World Leaders in all things RevSoft
