"MaximalVariance" <StephenTGallagher (AT) gmail (DOT) com> schreef in bericht
news:1181223683.766613.23930 (AT) q69g2000hsb (DOT) googlegroups.com...
Presume you have at least version 7, but better 8.5.

It has a nice function
FieldNames(fileName;layoutName)Create a layout with all fields on it (easy
enough) <AllFields>
Goto that layout
create a calc Fieldnames ( Get ( Filename) ; "AllFields" )
this will return a return delimited list with all FieldNames.
Easy enough to store and reuse, looping through the list.

Keep well, Ursus

On Jun 7, 6:41 am, MaximalVariance <StephenTGallag... (AT) gmail (DOT) com>
wrote:
I know I'm late to the party, but here's what I'd do:
My assumptions:
You have 3 tables.
You have n=500 fields in each of Table1, table2, and table3. and you
want to evaluate:

if(Table1[n] == Table2[n])
table3[n] = "yes", else table3[n]="no"

And you want this to be done with minimal labour.

Fortunately looping through and assessing Table1[n] == Table2[n] can
be easily done; unfortunately the same is not true for Table3[n].

So, we need a hack.
I'd put all 500 hundred target fields from table3 on a layout, then:

set $counter = 1
goto field first
loop
set field = if (Evaluate["table1::field"&n&" == table2::field"&n],
"yes", "no")
exit loop if $counter=500
$counter + 1
goto field next
end loop

Now this is simplified somewhat.

You may have to set up a bit more to ensure the context is suitable
for the evaluate to work, but I don't expect that to be an issue.

Also if your fields are not conveniently numbered field1..field500 you
can pass the field names in as a list (which is easy enough to
generate), and then you can do something like this to evalutate the
nth fields:

Evaluate(
GetField(MiddleValues(table1list,counter)) & "==" &
GetField(MiddleValues(table2list,counter)
)

(Note you may have to pre-pend the "table::" references to the field
names, if they are not already in the list.)

All that said, I strongly suspect your database design is flawed if
you have 500 fields that you want to iteratively work with. They very
likely should be blown out into a separate table.

This gives you the flexibility to work with portals, which DO allow
you to directly specify the nth record, making your script a lot more
elegant. and your database design much cleaner too.

For example If I am storing 500 attributes about an entity, I usually
find it makes more sense to abstract the attributes into an 'attribute
entity'. And then instead of dragging around a datamodel with 500
fields, I have much simpler one with a basic one-many relationship
between the parent object and all its attributes. Each attribute is
simply a { parentid, attributename, value } triplet. And in this case
each parent would have 500 children. (In a perfect world, you'd
further abstract attribute name out to an attributeid, and then store
the { attribute name / attribute id } pairs in yet another table, but
that may or may not be worth the effort.

To make it concrete, lets say it was a database of people: for each
person I want to track:

home phone, cell phone, car phone, fax phone, office phone, cabin
phone, emergency phone, pager phone, boat phone, toll-free phone.

rather than create 10 or so phone fields, I'd just create a related
phonenumbers file:
{personid, phonename, phonenumber}

and it would hold things like:

{123, boat phone, 555-1234}
{123, office phone, 555-1455}

In this case you have the added flexibility of duplicating types if
you want, or leaving types out. Or you can enforce constraints so that
all 10 related records are present and filled out.

-cheers,
Dave

On Jun 8, 5:45 pm, Helpful Harry <helpful_ha... (AT) nom (DOT) de.plume.com>
wrote:
Variables are not limited in the way you think they are. In the two
examples above, the first wouldn't work, but that's a limitation of
Set Field, not variables. And the second would work fine, based on
the value of the field at the time you set the variable. The field
itself is not evaluated when the variable is, but rather the contents
of the variable are set to the fields contents.

I've found variables to be very robust, except for the 'repeating'
feature, which is kind of bogus.

G

Harry, the OP was talking about script parameters. With 8 you can set a
variable and use this

Set Variable <$MyVariable ; MyValue>
Perform Scipt <Somescript ; $MyVariable>

Now you see how the variable can hold any value from the list with
fieldnmames and parse it to a second script as scriptparameter.

Ursus

In article <1181395485.928770.160230 (AT) m36g2000hse (DOT) googlegroups.com>,
Grip <grip (AT) cybermesa (DOT) com> wrote:

Yes, variables are great, but they are really only a temporary storage
space.

The second example will work if the variable $MyVariable contains the
data "My Value" ... but it won't work if $MyVariable contains the data
MyField_1 and you are wanting to see if the MyField_1 field itself
contains the data "My Value".

It's this second re-direction using varibales / parameters that the
original question was about and can't be done that easily. In
programming languages like C these would be called pointers - they
don't hold the data themselves, but point to the real location where
the data is stored.

Other people have given examples using a new GetField in function that
means such re-direction may work by changing the second example to be
something like:

If (GetField($MyVariable) = "My Value" ...

This function, if it works as it appears to, could make simple
variables a lot more powerful for some uses than as simple storage
spaces.


Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)