Could this be a bug in FilePro? (Was--Weird output with associated field)
Boaz Bezborodko
boaz at mirrotek.com
Wed Jan 30 09:06:51 PST 2008
Joe Chasan wrote:
> On Tue, Jan 29, 2008 at 11:04:25PM -0500, Boaz Bezborodko wrote:
>
>> Joe Chasan wrote:
>>
>>> On Tue, Jan 29, 2008 at 09:27:25PM -0500, Boaz Bezborodko wrote:
>>>
>>>
>>>> OK, I found out that the problem occurs when I use indexing to go
>>>> through the sort/selection processing to speed up the operation and that
>>>> it only occurs when this particular record is the first to appear in the
>>>> selection set in the index. If I change the selection set to start on a
>>>> day before, or I change the date field in the record so that it is a day
>>>> later, (IOW if the record is no longer the first to be selected) then
>>>> both associated fields appear correctly on the report. (BTW, if I added
>>>> more data to the other associated fields they also wouldn't show.) But
>>>> anytime it is the first record to be selected then only the first
>>>> associated field appears. This is true for 3 other records that are
>>>> identical to the first, but for 3 other months. In all cases the records
>>>> appear as the first in the indexed selection set.
>>>>
>>>> I also tried this with other records that have more than one entry in
>>>> associated fields that would be the first in the indexed selection set.
>>>> In all cases only the first associated entry is displayed and all others
>>>> are missing.
>>>>
>>>> Either I am doing something wrong (And I can't see where I am--though
>>>> I'm not as experienced as the rest of you) or there is a fundamental bug
>>>> in the way FP is working. (I'm using version 5.6.06D9.)
>>>>
>>>> I execute rreport with a -io ('o' index is on the invoice date field
>>>> '20'). I then ask for the beginning date (dummy field 'ba') and ending
>>>> field ('bb'). I then use this to jump to the first record:
>>>>
>>>> 32 ------- - - - - - - - - - - - - - - - -
>>>> b If: b
>>>> Then: lookup - k=ba i=O -bg b
>>>>
>>>> The selection processing then looks like this:
>>>>
>>>> 33 ------- - - - - - - - - - - - - - - - -
>>>> b If: b
>>>> Then: ai(10,mdyy/,g)="12/31/2050" b
>>>> 34 ------- - - - - - - - - - - - - - - - -
>>>> b If: '--------------------------------------------------------- b
>>>> Then: b
>>>> 35 ------- - - - - - - - - - - - - - - - -
>>>> SELECT b If: 20 gt bb b
>>>> Then: lookup - k=ai i=O -bg b
>>>> 36 ------- - - - - - - - - - - - - - - - -
>>>> b If: ag ne "" and ag ne 17 b
>>>> Then: END b
>>>> 37 ------- - - - - - - - - - - - - - - - -
>>>> b If: MID(30,"1","13") eq "Keyoffs check" 'Keyoff checks should not be>
>>>> Then: END b
>>>> 38 ------- - - - - - - - - - - - - - - - -
>>>> b If: 20 ge ba and 20 le bb and aa="" and 19 ne "AD" b
>>>> Then: SELECT b
>>>>
>>>> This selects every record with '20' within 'ba' and 'b'. Even the record
>>>> I'm missing gets selected for the first associated field in the record.
>>>> But the second associated field never shows up even though other records
>>>> with something in the second associated field get printed.
>>>>
>>>> The Sort for the output file looks like this.
>>>>
>>>> b bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb Field list bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
>>>> b 1- VENDOR NAME (RANDOM 11- CHECK NUMBER (ALPHA 21- due date b
>>>> b 2- address 1 (r 12- VOUCHER NUMBER 22- address line 3 b
>>>> b 3- address 2 (r 13- discount base 23- VENDOR NAME (RECENT b
>>>> b 4- city 14- terms (days) 24- date units received b
>>>> b 5- state 15- discount (days) 25- sales tax code b
>>>> b 6- zip 16- discount percent (% 26- taxable amount b
>>>> b 7- code for memo 17- VENDOR NUMBER 27- remarks b
>>>> b 8- CHECK NUMBER (NUMER 18- invoice amount 28- date posted b
>>>> b 9- date paid 19- invoice or debit me 29- customer ship-to (f b
>>>> b 10- CHECK AMOUNT 20- invoice date 30- INVOICE NUMBER b
>>>> bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
>>>> =A2
>>>> b bbbbbbbbbbbbbbbbbbbbbbbbbb Sort definition bbbbbbbbbbbbbbbbbbbbbbbbb
>>>> b b
>>>> b Sort Field: 61 b A1)b 1 b 28 b 9 b b b b b
>>>> ---b Length: 0b 5b 30b 8b 8b b b b b
>>>> b Descending: b b b b b b b b b
>>>> b Subtotal Field: fb xb xb b b b b b b
>>>> b b
>>>> le:bbbbbbbbbbbbbbbbbbbbbbbbbbbPress ESC To Record, Ctrl-C To CancelbETD
>>>>
>>>> Press F10 for help
>>>>
>>>> And the output looks like this:
>>>>
>>>> !@td
>>>> !@tm P U R C H A S E J O U R N A L
>>>> *ba - *bb
>>>>
>>>> V E N D O R INVOICE NUMBER DATE REC'D DATE POSTED DATE PAID AMOUNT R E M
>>>> A R K S
>>>> ===============================================================================
>>>> D A T A L I N E S
>>>> *1 *30 *24 *28 *ae*9 *A2 *ad
>>>> _____________________________T O T A L L I N E
>>>> S______________________________
>>>> SUBTOTAL BY VENDOR NAME (RANDOM) INDEX E
>>>>
>>>> SUBTOTAL BY A1) GL NUMBER 1
>>>>
>>>> *A1 *ab
>>>>
>>>> As far as I can tell everything looks kosher. What am I missing?
>>>>
>>>> Boaz
>>>>
>>>>
>>> I did not follow this entire thread but my guess is you can't combine
>>> 'lookup -' from a non-associated field built index with associated field
>>> sort. what you are doing in effect then is changing sort mid-report - the
>>> report starts out sorted by index O in your case (the '-i0' on command line
>>> and 'lookup -'), and AFTER it selects first record, you are then asking
>>> filePro to resort all by associated field - i'd guess the first record that
>>> gets selected then would have unexpected results on which, if any, of its
>>> associated fields would get seen/selected (because when it went into
>>> that record it was not doing an associated field sort). your results
>>> seem to back this up, as if @af="1" - e.g. on that record they were
>>> not associated.
>>>
>>> --
>>> -Joe Chasan- Magnatech Business Systems, Inc.
>>> joe - at - magnatechonline -dot- com Hicksville, NY - USA
>>> http://www.MagnatechOnline.com Tel.(516) 931-4444/Fax.(516) 931-1264
>>>
>>>
>>>
>> This shouldn't be a problem. The sort/selection processing is supposed
>> to go through the records in the order of the index and add selections
>> based on the sort parameters. I'm not switching it one way of the
>> other, merely selecting based on a non-associated field.
>>
>
> thats not how i see it. if my guess/suspicions are correct, then from my
> perspective, when you go through a file of 100 records based on normal
> sort, you see 100 records that *report has to go through - when you go
> through a file of 100 records with report sorted by associated field of
> which there are 5 occurences, *report sees 500 records - so if you change
> sort from regular to associated field mid-way, the first record that is
> selected when this happens will only get seen once, and only the ones
> after get seen 5 times (in this example).
>
> --
> -Joe Chasan- Magnatech Business Systems, Inc.
> joe - at - magnatechonline -dot- com Hicksville, NY - USA
> http://www.MagnatechOnline.com Tel.(516) 931-4444/Fax.(516) 931-1264
>
>
Maybe Ken could help us here, but as I see it, FP goes through 100
records and selects as many data items as the Sort table says it should
look for based on whether there are associate fields to sort. If you
step through the sort/selection table in debug it sees (in your example)
100 records, but selects 500. The same thing is happening in my
scenario except that the first record. In that instance only the first
associated field is selected.
I might see how what you suggest is happening could occur if I included
a "SORT1=A1" in the Sort/Selection processing table, but I'm not. The
sort is in the Output from the very beginning so FP should "know" that
it has to look for the associated fields from the very beginning.
Boaz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.celestial.com/pipermail/filepro-list/attachments/20080130/bf629db3/attachment-0001.html
More information about the Filepro-list
mailing list