Passing Values in Array

[Scott Walker]

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