Puzzler of the day - 5.0 Windows Setup

[Nancy Palmquist]

Ken,

If I have a chance to troubleshoot this again, I will try that.  I did 
add a -o9 to the menu so I could see if the duplication was happening 
before or after the generating.  Since only the computer for the person 
that runs this job is misbehaving, and I have no access to that 
computer, it is hard to work on this problem all the way to a solution 
that you or I would like which is to get to the bottom of it.

We determined that the most cost-effective solution is to just have her 
run it on the server.

I will add a bit of history.  They have been running this process for 
years.  First report of an issue was the start of this year.  Usually if 
she logged off or restarted the process it would work correctly.  As we 
noted if she selected differently, it would also work.

But this month there was no solution.  We tried everything and ran this 
function many times in all kinds of combinations.

What changed?  All of the desktops in this installation run XP but they 
do have varying amounts of memory.  Her particular computer had more 
memory installed sometime in the last 4 months.  Not sure if the timing 
matches but that is a weird thing to cause a problem.

Also, I am sure we have made some minor changes to the processing.  
Since it runs correctly from every other computer we tried, I think the 
programming is faultless in this regard.

The process usually runs with Scan/select ON and it is a selection that 
is a range on an indexed field (GE this number and LE that number).  I 
expect it might trigger the scan/select index logic, but it does seem to 
behave like it is doing a normal selection.  Since I do not use lookup 
Dash, an actual scanning of the index might fix the problem, because the 
records are not duplicated in the index.

That is all I have on this.  A weird issue.  It is strange that all the 
records before a certain point are gone from the result entirely.  It is 
almost as if the index that filePro is building to generate the report 
is starting over at that point.  And then the records are all entered 
twice after that.  My guess is that it creates two rp* files to collect 
the records but somehow when it is reading them to build the sort it 
reads the same one twice.  One is lost (which explains why the records 
before are all missing) and the remaining files records are all listed 
twice.  That is my guess from my experience with filepro and its files.  
I can not say WHY but that is what Ken always has to figure out.

Nancy

On 5/3/2011 5:23 PM, Kenneth Brody wrote:
> On 5/3/2011 5:15 PM, Kenneth Brody wrote:
> [...]
>> How about having your sort/select processing log each record number
>> processed, along with "selected"/"not selected", and see what you 
>> get?  How
>> does computer B compare to the ones that work?
>
> Note that, since you have turned index scan off, and you are not using 
> lookup-dash in sort/select processing, the records will be in 
> record-number order.
>
> Also, you should probably include the account number in the log, as 
> well as anything else you might find useful, to help see what's going on.
>
> Of course, given the same selection criteria on the same database, all 
> computers _should_ give identical logs.  The question is "what is 
> different in computer B's logs, and why".
>

-- 
Nancy Palmquist         MOS&  filePro Training Available
Virtual Software Systems    Web Based Training and Consulting
PHONE: (412) 835-9417           Web site:  http://www.vss3.com