Select Looping (AREV Specific)
At 13 JUN 2002 06:10:44AM Serguei wrote:
One of our client experiences the following problem:
The programs containing SELECT and then loop with READNEXT from time to time in the middle of the process would start processing records that have already been processed (restarting select). It happens very inconsistent and no error message is generated. When the data restored from backup the save process might work OK. We are unable to repeat the problem in our office on the same data. What happens?
Serguei
At 13 JUN 2002 06:59AM [url=http://www.sprezzatura.com" onMouseOver=window.status= Click here to visit our web site?';return(true)]The Sprezzatura Group[/url] wrote:
Is the file a very active one?
World Leaders in all things RevSoft
At 13 JUN 2002 07:02AM Serguei wrote:
It is been modified every day.
At 13 JUN 2002 07:29AM Hippo wrote:
How looks the header of the file (frame 0 first 2 lines obtained by DUMPLH)?
I thing there is an error in RBasic part of the READNEXTing loop.
It sometimes calls Base file system (MFS,BFS) with wrong FMC pointer.
(Pointer identifying the progress of READNEXTing loop.)
My suspections where that when FF hex appears in FMC, the FMC is cut in this FF, but I stop researching (as I have no access to the source codes and the problem was solved by a MFS guard).
… by the way, my description of FMC does not hold in all cases, but I dont waste time to research this undocumented feature more.
I opened here a discussion in 12/2001, but the topic vanished.
It may be interested to trace the READNEXTING loop
(using MFS specialy mounted for this purpose).
At 13 JUN 2002 08:08AM [url=http://www.sprezzatura.com" onMouseOver=window.status= Click here to visit our web site?';return(true)]The Sprezzatura Group[/url] wrote:
Does it process ALL of the records again or just SOME of them?
World Leaders in all things RevSoft
At 13 JUN 2002 08:57AM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:
What version of ARev is this?
There was a bug in pre 3.12 versions that would cause the next group pointer to get corrupt. It involves very large files and low memory contitions. It was fixed in 3.12 and with the NLM and NPP drives for older versions.
World Leaders in all things RevSoft
At 13 JUN 2002 09:19AM Don Miller - C3 Inc. wrote:
I've also seen this behavior with latent selects. If you're going to update data, then make sure that the select is resolved. To be sure, I usually do an R/LIST select and do not include the NORESOLVE parameter.
Don Miller
C3 Inc.
At 13 JUN 2002 01:40PM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:
If I'm doing a latent select, I'll usually bump up the sizelock while processing, then drop it back later. That's what the select processor does while it's revsolving a select. There's a program to modify sizelocks in Disk 4 or 5, though I think 5.
World Leaders in all things RevSoft
At 13 JUN 2002 01:46PM Don Miller - C3 Inc. wrote:
Yes, indeed there is and I've used it. However, if someone doesn't have it and tries to update while a latent list is active, it's entirely possible that a record may be processed more than once due to resizing. Mostly, I stamp a record with a last-updated field anyway and check it during update anyway .. but it doesn't hurt.
Don
At 13 JUN 2002 01:52PM Victor Engel wrote:
But records could also be skipped. Your timestamp doesn't solve that problem.
At 13 JUN 2002 02:59PM Dave Harmacek wrote:
Isn't the purpose of the SizeLock to prevent resizing when there is an "unresolved" select on the table? It bumps the sizelock, first to 2, then by 2.
He can look at the sizelock of the table with dumplh during that select and see the value.
At 13 JUN 2002 05:16PM Victor Engel wrote:
That's true, but a latent list works differently, resolving not with the select but with the readnext calls.
At 14 JUN 2002 03:32AM Serguei wrote:
Just some of them. As a result about 1/2 of records is processed twice and the rest only once.
At 14 JUN 2002 03:33AM Serguei wrote:
3.12 with NT Linear Hash Service
At 14 JUN 2002 04:03AM [url=http://www.sprezzatura.com" onMouseOver=window.status= Click here to visit our web site?';return(true)]The Sprezzatura Group[/url] wrote:
Can you try setting the sizelock to say 4 (DUMP the file, increment the size lock by pressing + a couple of times) then exit and rerun the program and see if it still happens?
The sizelock will prevent the file from resizing and thus rehashing records you have processed already into another location.
World Leaders in all things RevSoft
At 14 JUN 2002 02:53PM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:
Setting sizelock is the only way to do this, in my opinion. But the file would have to be really active to cause that many duplicates, and the records would have to hash back out, and from a point always earlier in the file than the current pointer.
I'd still always use the sizelock call when doing a latent select, but in this case, I'm going to go with the pointer offset bug.
World Leaders in all things RevSoft
At 18 JUN 2002 06:02AM Hippo wrote:
The bug I was talking about was during resolution of TCL SELECT,
not a latent RBasic select.
I am sorry for confusing anybody (if the "bugs" are independent).