limits on called program's variable and/or array space?

[Richard Kreiss]

Setting the -p to lock records in a browse lookup is a bad practice as it slows down the browse as each record has to be locked. To avoid this problem, gat the record number of the record to be updated, and the go to a sub-routine that updates the locked record. This included possibly putting up an overlay screen so that it appears that the browse record is being updated in the browse. 
This is visually effective but a pain to program. 


Richard
Sent from my iPhone

> On Jul 4, 2018, at 6:49 AM, Jose Lerebours via Filepro-list <filepro-list at lists.celestial.com> wrote:
> 
> Have you made sure that records are locked prior to updating?
> 
> Even if you rebuild index/chain prior to each run, not locking the record prior to updating will likely cause the same problem again ...
> 
> I have come across so many processes where -p is not used in routines where records are being updated - This is even worse if the index key(s) is/are being altered.
> 
> 
> 
>> On 07/03/2018 05:30 PM, Richard Veith via Filepro-list wrote:
>> I made a number of the changes that had been suggested, including increasing the sizes of PFTOKSIZE and PFFORMTOKSIZE (though to 500000 rather than 900000), and remade the indexes involved, but after 6 hours or so of running, and definitely getting farther along in the process than it had before, it still aborted before the end.   I will increase those settings to 900000 and see if that makes the difference.
>> 
>> As for Jeroen's suggestion for using Windows Performance Monitor, I have not used it before but guess it is time to dig into it.
>> 
>> Thanks,
>> Rich
>> 
>> -----Original Message-----
>> From: Filepro-list [mailto:filepro-list-bounces+richard.veith=smrresearch.com at lists.celestial.com] On Behalf Of Bruce Easton via Filepro-list
>> Sent: Tuesday, July 03, 2018 11:55 AM
>> To: 'filepro-list at lists.celestial.com' <filepro-list at lists.celestial.com>
>> Subject: Re: limits on called program's variable and/or array space?
>> 
>> If that's what was printed there, Richard, I suspect it's a typo, and it should have read 999999.  I don't ever remember reading about such a limit in any of the printed manuals, but I may have missed it. I do believe I've had to use values well above 100,000 to get past issues before.
>> 
>> Note that in filepro 5.6 and later the default is 100000 for PFAUTOTOKSIZE, PFTOKSIZE, and PFFORMTOKSIZE. (From online manual at
>> fptech.com.)
>> 
>> Bruce
>> 
>> 
>>> On 7/3/18 11:31 AM, Richard Kreiss wrote:
>>>    
>>>   For the PFFORMTOKSIZE-nnnnn  - default is 15,000 bytes PFTOKSIZE =
>>> nnnnn - default is 20,000 bytes
>>> 
>>> PFAUTOTOKSIZE - nnnnn - default is 15,00 bytes
>>> 
>>> Referring to filePro Developers reference fourth edition
>>> 
>>> It appears that the maximum value would be 99999.  I have used values higher than this, for debugging purposes, but don’t know how effective in adding additional memory space thes