Patti: If you are truly using "indicator variables", then that is not what you want to do. The only thing indicator variables do is act as a temporary holding spot in case of a null variable value, used mostly so that they do not throw up a warning message while you are debugging your code.
Maybe post an example of your code for us to review? I'm sorry, but I couldn't understand enough from your explanation to offer you code to try... Karen In a message dated 6/7/2011 12:47:59 PM Central Daylight Time, [email protected] writes: > From time to time, I would find life so much easier if rbase had some > sort of Array logic that I could use when writing code. Maybe there's some > other way of doing this that someone could point out to me. > > I have a database table with about 60 yes/no data fields in it. I need > to write a one-page report per client that lists only the boxes that were > checked "yes." So I've fetched the data into variables with indicator > variables, that I've named vi1, vi2, vi3, etc. I'm trying to write some sort > of > "for/next" or "while" loop that will: > set my beginning loop counter to 1 > LABEL Beginloop > set MyVariable representing the indicator variable to ('.vi'+loop > counter) > check MyVariable (which would hopefully check the real indicator var) > if something other than 0, write it in a temp table (which I could use > for generating the rpt) > increment the loop counter > goto LABEL Beginloop > > What I've tried won't ever give me the actual value of the indicator > variable. It thinks MyVariable is a text field called .vi1 or .vi2 > > I considered having a table of just those fields that were marked "yes" > for each client, but that creates bothersome code-writing when I have to > allow data-entry people to make changes or send the entire data record off to > another health dept. So it would be easier in the long run to have them > all in one table. > > Does anyone have any idea of how I replicate Array type code in Rbase > without having to write code for each of the 60 fields? Or maybe there's > some > other way of setting up this table that will be better suited to doing > both types of tasks? > > Thanks, > Patti Jakusz >
