Help on Report
Jose Lerebours
fpgroups at gmail.com
Wed Jul 15 11:40:20 PDT 2020
Got it.
I am one that "never" used demand indexes - One of the following reason:
1. Never really understood their benefit,
2. I figured that the time it took to create the index.[0-9] based on
"selection set" is pretty much the same time (or longer) that it took me
to run through using -v combined with -i[A-Z]
I understand that if one created the selection set dynamically, there is
the added value of creating a "sorted" block of records that meat your
"selection" criteria but, having developed means to pass any number of
values to the -v processing, I stuck to my old ways that "always" worked
for me.
Talk about not learning "new tricks" - I may have missed out and
overworked for not having experimented with demand indexes.
On 7/15/20 2:14 PM, Bruce Easton via Filepro-list wrote:
> 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
>
>
> _______________________________________________
> 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