Help on Report

Bruce Easton bruce at stnincmd.com
Wed Jul 15 11:14:47 PDT 2020


Actually, what I wrote below is not correct.  For auto indexes, I 
believe using the -I would only matter for the order of reading records 
phase as part of selection.  I would agree that mostly I've only used 
that to speed up reports, but have used it to make debugging easier for 
the selection phase.   But for a demand index, I can think of the index 
used with -I as being the a [pointer] source in lieu of the key.


On 7/15/20 1:48 PM, Bruce Easton via Filepro-list wrote:
> Using -i on the command line simply means processing the selected 
> records in the order specified by the index.  There may be other 
> reasons to do this other than speeding up a report.  (I.e., keeping 
> track of when one or more of the sorting key values has changed for 
> certain types of layout requirements.)
>
> "that run time will use the given index.[?] as source of data in lieu 
> of key"
>
> Not exactly -  I wouldn't put it like that.  BUT based on the 
> selection already done with -v and/or extended selection,  the 
> temporary reporting index (for auto indexes) or the actual demand 
> index should only have pointers for the selected records.  (For demand 
> indexes, the selection done when the index was built.)
>
>
>
> On 7/15/20 12:09 PM, Jose Lerebours via Filepro-list wrote:
>> Wait, I understood that using -i[?] simply meant that one can use the 
>> -v processing to perform lookup thus reduce the process by directing 
>> pointer to the block of records you are interested in.
>>
>> Are you saying that using -i[?] means that run time will use the 
>> given index.[?] as source of data in lieu of key?
>>
>> Based on my understanding, there is no reason to invoke -i[?] unless 
>> you are performing lookup - to move record pointer.  BTW, this 
>> technique runs through thousands of records and retrieves a block of 
>> them in a blink of an eye - hence the blessings realized when filePro 
>> increased the number of automatic indexes.
>>
>> Back to OP: Have you resolved your issue?  Still looking for a solution?
>>
>>
>> On 7/15/20 11:07 AM, scooter6 at gmail.com wrote:
>>> Yes     rreport  client  -f  summary -u -a -v select -ih     with 
>>> index H being received date
>>>
>>> On Wed, Jul 15, 2020 at 11:04 AM Richard Kreiss via Filepro-list 
>>> <filepro-list at lists.celestial.com 
>>> <mailto:filepro-list at lists.celestial.com>> wrote:
>>>
>>>     Are you using a -v selection process?
>>>
>>>     I am going to assume that you are already indicating the index
>>>     mentioned on the command line. Is this assumption correct?
>>>
>>>
>>>
>>>     Richard
>>>     Sent from my iPhone
>>>
>>>     > On Jul 15, 2020, at 7:32 AM, Jose Lerebours via Filepro-list
>>>     <filepro-list at lists.celestial.com
>>>     <mailto:filepro-list at lists.celestial.com>> wrote:
>>>     >
>>>     > Call me crazy but doesn't filePro allow for the "sort" to be
>>>     changed from within the -v processing table?
>>>     >
>>>     > If that is the case, will not work if you
>>>     >
>>>     > a. convert date into a YY-MM-DD format
>>>     > b. create string like so DATE + CONTROL + [ whatever ]
>>>     >
>>>     > use filePro available method to set the sort order. By the time
>>>     your processing triggers, your data should be in the order you 
>>> desire.
>>>     >
>>>     > If filePro does observe the "date" field as a "date" and not as
>>>     string when sorting, I fail to see how this cannot be done using
>>>     standard sort settings ASC/DES combination.  Of course, if your
>>>     fields are not in sequence, using the -v table might be the way 
>>> to go.
>>>     >
>>>     >
>>>     >> On 7/15/20 6:03 AM, Jeff Harrison via Filepro-list wrote:
>>>     >> It's been a while, but I think that you can leverage the min
>>>     and max functions for this.
>>>     >> In your processing at line 1 (before the @brk) do something
>>>     like ;Aa=min(acctfield) ; ab=max(acctfield)
>>>     >> Now you can reference aa and ab when you are at the break and
>>>     will have the expected values.
>>>     >>
>>>     >> Sent from Yahoo Mail on Android
>>>     >>     On Wed, Jul 15, 2020 at 1:59 AM, scooter6--- via
>>>     Filepro-list<filepro-list at lists.celestial.com
>>>     <mailto:filepro-list at lists.celestial.com>> wrote:  I guess that's
>>>     the part I'm struggling with - since I'm using index for
>>>     >> date, the first record it finds may not be the lowest number in
>>>     that 'batch'
>>>     >> Would it be better to create an index on date and full account
>>>     number, then
>>>     >> grab the first 'acct'?
>>>     >> thanks
>>>     >>
>>>     >>
>>>     >> On Mon, Jul 13, 2020 at 3:59 PM Bruce Easton via Filepro-list <
>>>     >> filepro-list at lists.celestial.com
>>>     <mailto:filepro-list at lists.celestial.com>> wrote:
>>>     >>
>>>     >>> Scott - if the only problem is the Starting Acct#, then, are
>>>     you using a
>>>     >>> global field to track when the Starting Acct# is less than one
>>>     >>> previously encountered within a Ctl#?  (And then resetting it
>>>     back to
>>>     >>> an arbitrarily high value when you start a new Ctl# after
>>>     reporting the
>>>     >>> Ctl#?)
>>>     >>>
>>>     >>> Bruce
>>>     >>>
>>>     >>>
>>>     >>> On 7/13/20 2:12 PM, scooter6--- via Filepro-list wrote:
>>>     >>>> I have a database that has this type structure
>>>     >>>>
>>>     >>>> Clt            Acct          Full Acct     Date Received
>>>     >>>> -------        --------- ----------------------
>>>     >>>>   -----------------------
>>>     >>>> 01234        00010      01234-00010 06/01/20
>>>     >>>> 01234        00011      01234-00011 06/01/20
>>>     >>>> 01234        00012      01234-00012 06/05/20
>>>     >>>> 01234        00013      01234-00013 06/10/20
>>>     >>>> 01235        00250      01235-00250 06/01/20
>>>     >>>> 01235        00251      01235-00251 06/05/20
>>>     >>>>
>>>     >>>> I want to create a report with oldest received date first and
>>>     a 'summary'
>>>     >>>> line for each batch then in Clt number order
>>>     >>>>
>>>     >>>> For example, for the above data set, I want to see
>>>     >>>>
>>>     >>>> Date Rec'd      Clt            Starting Acct     Ending Acct
>>>     >>> Total
>>>     >>>> in Batch
>>>     >>>> ---------------      ----------- -----------------
>>>     >>>> ---------------- ------------------
>>>     >>>> 06/01/20          01234        00010 00011
>>>     >>>>           2
>>>     >>>> 06/01/20          01235        00250 00250
>>>     >>>>           1
>>>     >>>>                             Total Received 06/01/20
>>>     >>>>                 3
>>>     >>>>
>>>     >>>> 06/05/20          01234        00012 00012
>>>     >>>>           1
>>>     >>>> 06/05/20          01235        00251 00251
>>>     >>>>           1
>>>     >>>>                             Total Received 06/05/20
>>>     >>>>               2
>>>     >>>>
>>>     >>>> 06/10/20          01234        00013 00013
>>>     >>>>           1
>>>     >>>>                               Total Received 06/10/20
>>>     >>>>                 1
>>>     >>>>
>>>     >>>>
>>>     >>>> When I do @wbrk1 - I can get the Ending Account and the Total
>>>     but even
>>>     >>> if I
>>>     >>>> declare the Starting Acct before @wbrk1 - both variables
>>>     still come out
>>>     >>> the
>>>     >>>> same - so I'm apparently missing something there
>>>     >>>>
>>>     >>>> I'm using sort order of Date Rec'd and descending and
>>>     subtotal and
>>>     >>> subtotal
>>>     >>>> on Clt
>>>     >>>> Running this rreport with -ih  (index H which is Date Rec'd)
>>>     >>>>
>>>     >>>> I can post full processing table if that helps - but each
>>>     report dataline
>>>     >>>> is a field in the actual file
>>>     >>>> There is a little more I'm doing with it other than this, but
>>>     it's really
>>>     >>>> just displaying a few of the other fields - so didn't want to
>>>     confuse by
>>>     >>>> posting the full prc table
>>>     >>>>
>>>     >>>> thanks
>>>     >>>> Scott
>>>     >>>> PDM
>>>     >>>> -------------- next part --------------
>>>     >>>> An HTML attachment was scrubbed...
>>>     >>>> URL: <
>>>     >>>
>>> http://mailman.celestial.com/pipermail/filepro-list/attachments/20200713/7231d1b1/attachment.html 
>>>
>>>     >>>> _______________________________________________
>>>     >>>> Filepro-list mailing list
>>>     >>>> Filepro-list at lists.celestial.com
>>>     <mailto: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
>>>     <mailto:Filepro-list at lists.celestial.com>
>>>     >>> Subscribe/Unsubscribe/Subscription Changes
>>>     >>> http://mailman.celestial.com/mailman/listinfo/filepro-list
>>>     >>>
>>>     >> -------------- next part --------------
>>>     >> An HTML attachment was scrubbed...
>>>     >> URL:
>>> <http://mailman.celestial.com/pipermail/filepro-list/attachments/20200714/670932b6/attachment.html> 
>>>
>>>     >> _______________________________________________
>>>     >> Filepro-list mailing list
>>>     >> Filepro-list at lists.celestial.com
>>>     <mailto:Filepro-list at lists.celestial.com>
>>>     >> Subscribe/Unsubscribe/Subscription Changes
>>>     >> http://mailman.celestial.com/mailman/listinfo/filepro-list
>>>     >>   -------------- next part --------------
>>>     >> An HTML attachment was scrubbed...
>>>     >> URL:
>>> <http://mailman.celestial.com/pipermail/filepro-list/attachments/20200715/5a657b03/attachment.html> 
>>>
>>>     >> _______________________________________________
>>>     >> Filepro-list mailing list
>>>     >> Filepro-list at lists.celestial.com
>>>     <mailto: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
>>>     <mailto: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
>>>     <mailto:Filepro-list at lists.celestial.com>
>>>     Subscribe/Unsubscribe/Subscription Changes
>>>     http://mailman.celestial.com/mailman/listinfo/filepro-list
>>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: 
>> <http://mailman.celestial.com/pipermail/filepro-list/attachments/20200715/53897ec8/attachment.html>
>> _______________________________________________
>> 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




More information about the Filepro-list mailing list