IDX_SETS errors FS445 (AREV Specific)
At 03 AUG 1998 06:14:36PM David Plass wrote:
I have a client who is getting sporadic IDX_SETS function errors
followed up by errant AREVC.INI and REVBOOT read errors.
They are currently on Win95 and WinNT stations on an NT network
(4.0), and they recently had everything moved around on them. I'm
thinking that there is a path that is not set properly, but I haven't been
able to track it down. Any ideas?
At 03 AUG 1998 11:09PM Aaron Kaplan wrote:
If it was just IDX_SETS I'd hemm and haw and all that, but add it to the others, and I'm thinking memory errors are server/connection hiccups. Have you run through the ARev FAQ and the Windows 95 Shortcut for Advanced Revelation.
They might help you manage the memory better.
At 04 AUG 1998 01:42AM Larry Wilson (TARDIS Systems, Inc.) wrote:
1) all workstations MUST be using the same logical drive letter to access AREV (i.e. F: or G: or whatever)
2) this may be two separate problems. If you are not on 3.12, the
IDX_SETS is most closely related to the SELECT bug in pre-3.12 AREV.
3) I always create a volume on the local C: drive (I call it, cleverly, C:\AREVLOC) where I create a LISTS table and have it attached last so that the LISTS is truly local, preventing conflicts).
4) Set your SORT path as C:\AREVLOC also.
5) Make sure your RESET command does not modify the above parameters
(or whatever verb (program) you use when they RESET, SYSTEMRESET or do and ESC at a break. Mine always includes and UNLOCKALL and a re-attach of C:\AREVLOC and resets the sortpath.
If you do these and problems still happen, please e-mail:
Larry Wilson
At 04 AUG 1998 05:23PM Aaron Kaplan wrote:
Before reading the rest of this, please this message about the select bug that I posted earlier.
IDX_SETS is not affected by this! It does not use the READNEXT logic in RTP57A!
IDX_SETS goes directly against the indexes and retrieves data by traversing the nodes. The only thing these items have in common is they both retrieve data. IDX_SETS is called during BTREE.EXTRACT or from REDUCE. That is it.
Your select bug occurs when a pointer to the next group is corrupted. It does not appear when records are read directly by keys, or when indexes are used for full retrieval or when a key list is already active.
If IDX_SETS is called, a key list is created and the system goes through a different process in which there is not a ReadNext pointer to corrupt.
I know this is a pet peeve of yours, but it is not the end-all, be-all answer to every problem under the sun. Stop bringing it up in situations it does not belong. If you want to harp on it, do it some other way.
At 05 AUG 1998 08:05AM David Plass wrote:
Thank you for your inputs. I've been tracking the IDX_SETS argument
in other subjects. Our clients are using 3.12 (ARev), so the 'bug' thing
isn't the issue. I'm still on the wavelength that there is a setting somewhere
that is causing a workstation conflict. They have not only migrated networks
but have also altered some workstation stuff, and outsourced IS. I think
something just got screwed up, but I'm still open to any other suggestions.
I'll keep you posted on their progress.
At 05 MAR 1999 01:50PM David Plass wrote:
It turns out that they had upgraded to NPP 1.5, but the way one of our internal functions was manipulating the station id was making everything flake out big time. I haven't read the specs for NPP 1.5, but something in there must not like something our application was doing.
I appreciate all of you inputs.