Latent Select losing pointer (AREV Specific)
At 11 MAY 1999 10:27:51PM Don Bakke wrote:
We have a utility that we've been using quite extensively for exporting LH to normalized ASCII tables. It is basically just one latent select (i.e. Select hTable).
We just had a wierd situation happen though. In a 1.2 million row table, after about 700K of records were processed the pointer restarted back to the first record and went through the 1.2 million. So the eventual exported row count was 1.9 million. We confirmed that the first 700K of records are identical to the the next 700K of exported records so it is fairly obvious that the pointer got reset.
Our code is very straight forward -
Select hTable
Done=No$
Loop
Readnext ID else Done=Yes$Until Done
Read Record from hTable, ID then......end else...endRepeat
What could cause this to happen? BTW, we've exported this table before a couple of times without this problem as well as several (40+) others without any incident.
Thanks for any tips,
dbakke@srpcs.com
At 12 MAY 1999 04:37PM KGilfilen wrote:
Don,
My understanding with that type of select is that it simply starts blindly at the beginning of the file, working its way through what ever keys it hits until it gets to an end-of-file marker. After readnext gets a key, it sets the pointer for the next key. But if the table adjusts itself (something we all do now and then) either due to the reading or to another unrelated write, the pointer probably won't be in the right place, and some new records may be written somewhere that the pointer has already been. Arev may just put the pointer back at the beginning, not knowing what else to do.
To fix this, you would lock everyone out while doing the operation, and use a different select, something that keeps a real list of keys in a file or in memory: perform "select the_file" or if you did a save list, perform "getlist list_name".
At 12 MAY 1999 07:09PM Don Bakke wrote:
Thanks for the information. This is a stand alone copy so there is no one else working in the system. The only writes are OSBWrites to DOS. We'd rather not do a resolved select because we need to pump this stuff out as soon as possible, although if this is the only way to avoid this problem then we would have no choice. It just seems odd that this would just happen out of the blue when nothing has been changed.
dbakke@srpcs.com
At 12 MAY 1999 10:28PM akaplan@sprezzatura.com - [url=http://www.sprezzatura.com]Sprezzatura Group[/url] wrote:
This is an old bug, and I'll explain later, but you should not be seeing this on ARev 3.12 or with the NPP or NLM drivers. Are you?
akaplan@sprezzatura.com
At 13 MAY 1999 09:03AM Don Bakke wrote:
Aaron,
FWIW - Arev 3.12, Non-networking driver, Win98, 300K available memory, 4MB expanded memory.
dbakke@srpcs.com
At 14 MAY 1999 10:09AM akaplan@sprezzatura.com - [url=http://www.sprezzatura.com]Sprezzatura Group[/url] wrote:
Well, as a far as I know, this shouldn't be happening, at least not in the versions you are using. There is a bug where the next group pointer sometimes gets corrupted, but I never heard of it jumping back to 0.
What you'll have to do is, load up the select into a numbered cursor instead. Then, check the first 4 bytes of @CURSOR(NUM,4).
CurrGroup=@CURSOR( CursorVal, 4) 1, 4
CurrGroup=( SEQ( CurrGroup1,1) + 256*SEQ(CurrGroup2,1) + 65536*SEQ(CurrGroup3,1) + 16777216*SEQ(CurrGroup4,1)
CurrGroup += 1
CurrGroup should keep increasing. CurrGroup will be the current group. We added 1 since LH treats group 1 as group 0, so everything internal is one off. Don't worry too much if you skip one or two, since empty groups will not be returned to you.
akaplan@sprezzatura.com