Hi Bill, I'll have to get my code into a more readable form before posting it. (I may not get a chance again until tomorrow.) I thought about doing the "narrow" table as you suggested (kind of a cross between your two methods), but I will have to build a "wide" table anyway, for sending data to other health depts. I was hoping to only have the wide one - but maybe it will be easier to have it both ways. Patti
--- On Tue, 6/7/11, Bill Downall <[email protected]> wrote: From: Bill Downall <[email protected]> Subject: [RBASE-L] - Re: need Array logic To: "RBASE-L Mailing List" <[email protected]> Date: Tuesday, June 7, 2011, 6:03 PM Patti, First of all, for the quick and dirty fix, show us a snippet of the actual code in your loop, and people are sure to jump in and help with a syntax that will work. It is possible to programatically build variable names and set values to them. On the bigger issue of arrays, the place where R:BASE comes close to arrays is the structure of a table itself. Often, I create a temporary table to do what I would use an array for in a different environment. I also would be more likely to design tables in a different way for this problem. For example, instead of a "wide" table with sixty Y/N columns, 1) A table with a row for each yes/no check-box type ChkBoxID ChkBoxAbbrev CheckBoxDescription -------- ------------ -------------------- 1 apples apples 2 bananas bananas 3 cukes cucumbers (The abbreviation column could conceivably become a source for variable names.) 2) And a "narrow" table with a row for each "yes" check for a client YesCheckID ChkBoxID ClientID ---------- -------- -------- 1 1 1001 2 3 1001 3 2 1002 4 3 1002 With a combination of outer joins, views, and temporary tables, you can produce any form or report you need. (You might also need an "order by" column in table #1 above, so that you can control display and report order without also having to have it be in alphabetical order.) And the best part is, that when you come up with a sixty-first check-box type, you don't have to rewrite any code, you just add a new code to table 1 above. Bill On Tue, Jun 7, 2011 at 1:46 PM, Patti Jakusz <[email protected]> wrote: Hi, >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
