Passing Values in Array

[Bruce Easton]

You're welcome, Scott.    I looked through some of my older auto tables, 
and
I see that there was some overkill.  I would declare each dummy field, and
then dim against them as in:

Then: aa(4,.0,g)
Then: ab(4,.0,g)
.. etc
Then: dim myar(99):aa

when all that was needed was:

Then: dim myar(99)(4,.0,g):aa


Bruce

On 11/9/11 10:55 AM, Scott Walker wrote:
> Bruce,
>
> Thank you.  That was indeed the missing step.
>
> Regards,
>
> Scott
>
>
>> -----Original Message-----
>> From: filepro-list-
>> bounces+scottwalker=ramsystemscorp.com at lists.celestial.com
>> [mailto:filepro-list-
>> bounces+scottwalker=ramsystemscorp.com at lists.celestial.com] On Behalf Of
>> Bruce Easton
>> Sent: Wednesday, November 09, 2011 10:37 AM
>> To: filepro-list at lists.celestial.com
>> Subject: Re: Passing Values in Array
>>
>> In addition to what Mike&  Jeff suggested, I believe your array will
>> have to be mapped to
>> dummy fields.  So I think the dim merely enables simple instantiation of
>> (and later
>> efficient access to) the global dummy fields that will communicate in
>> the usual way
>> with the other processing tables.  In this way, it's not even necessary
>> to name the arrays
>> the same between the tables - they just have to map against the same
>> dummy fields.
>>
>> Bruce
>>
>>
>> On 11/9/11 9:34 AM, Mike Schwartz wrote:
>>>> Is there a way to populate an array in Sort/Select processing and
>> access
>>> the
>>>> values in the array in Output processing?
>>>>
>>>> Scott Walker
>>> My tip for the day:
>>>
>>>        Jeff Harrison already suggested putting the array into the
>> automatic
>>> processing table.
>>>
>>>       I think you have to remember to make the array global; at least
>> I've
>>> always done that.
>>>
>>>        I also suggest creating a *separate* automatic processing table
>> with
>>> the (global) array in it and run the report using the "-Y" option on the
>>> d/rreport command line.  Some of the toughest troubleshooting problems
>> I've
>>> run into were caused by somebody adding new variables into the standard
>>> auto.prc or prc.automatic table without any regard as to whether those
>>> variables were used for some other purpose in the other output
>> processing
>>> tables.
>>>
>>>        By running a separate automatic processing table, you can also
>> bypass
>>> any unnecessary lookups or other calculations that are in the default
>>> automatic processing table, thereby speeding up your reports.
>>>
>>>        The downside is that if you do make any changes to your default
>>> automatic processing table, you have to check all of these other
>> automatic
>>> processing tables to see if you need to make the same changes to them.
>> You
>>> might want to consider a standard naming convention for these other
>>> automatic processing tables, like autocust, autohours, etc.
>>>
>>> Mike Schwartz
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Filepro-list mailing list
>>> Filepro-list at lists.celestial.com
>>> Subscribe/Unsubscribe/Subscription Changes
>>> http://mailman.celestial.com/mailman/listinfo/filepro-list
>>>
>>>
>> _______________________________________________
>> Filepro-list mailing list
>> Filepro-list at lists.celestial.com
>> Subscribe/Unsubscribe/Subscription Changes
>> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
>
>