Line break that leads to scrolling quickdex.mfs initialize (AREV Specific) [Revelation On-Line Wiki]

Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community

At 12 AUG 1999 03:59:36PM Irma Haney wrote:

AREV Specific

I have a run time license and Iam a netware engineer.

I just recently starting getting daily GFE's With 1.12 NLM I didn't have any for 2 years. They have slowed down considerably but most recently began getting errors on clients.

Sequence of events:Novell 4.11

I installed a new server then loaded NLM 1.5a and about a month later

began having GFE's and quickdex problems. Most recently I loaded the Turbod.nlm hopefully that will help with the GFE's but quickdex seems to have picked up speed

Clients 95/98 getting line break with quickdex

ERROR

Error RTP57 line 1 b114 Maximum number of variables exceeded

Line 1 'v23' broke because a run time error was encountered.

esc to leave debugger.

Once you escape then a blue screen with the following message scrolls in an endless loop until you end the task.

errmsg r27 quickdex.mfs initialize

Most of the time this happens as users move from one application to another by alt tabing or just minimizing the screen to move from one to the other. Sometimes when the program has been idle and sometimes not.

I have read most of the tech notes and tried numerous suggestions to no avail.

Help!

Novell 4.11 w/ Adv. Rev. NLM 1.5a/

Clients 95/98 with client32 3.0.1 & 2.2

Frame types on all machines set to 802.2

4096 expanded mem

no extended

At 12 AUG 1999 06:13PM Warren wrote:

The quickdex record has probably exceeded the 64K limit. This is dependent on the number of records in the file and the length of the key.

If this is the case, the only thing you can do is remove quick/rightdex from the file.

At 13 AUG 1999 11:31AM Irma Haney wrote:

Thank you for responding. I have checked and am not exceeding the 64K

limit. Let me know if you have any other suggestions…

At 14 AUG 1999 12:20AM Warren wrote:

How did you determine this? If you have fixed length keys then the %RECORDS% (quick/rightdex) record would be ¹⁾

¹⁾

len(@ID) + 1) * no. records) - 1. For variable len keys you could create a symbolic IDLEN in the VOC file where @ans=len(@id) + 1 and then do a list xfile total IDLEN det-supp. The size would be off one byte but so what? You could also editing the %RECORDS% record in the data file and doing a shift f3. Depending on how much string space you have available it could crash way before reaching the 64K limit too. I would try removing QUICKDEX anyway and see if it solves the problem. </QUOTE>

=== At 14 AUG 1999 01:52PM [email protected] - Sprezzatura Group wrote: ===

If this happens as a result of switching applications, then one of your applications (not ARev) is seriously misbehaving*. It's swapping out the current drive path and forcing the new setting to all other sessions. ARev works on a relative path scheme and assumes that the path will never change.Best solutions is map a new drive and use that drive letter for ARev [email protected]Sprezzatura Group *OK, one can argue that ARev should not be concerned about relative paths and work with the absolute one, but that's nowhere near as serious a problem than redefining other sessions's settings.

=== At 16 AUG 1999 04:43PM Irma Haney wrote: ===

We have a utility that checks the filesize and it didn't find any files too large.Thanks for your response.

=== At 16 AUG 1999 04:44PM Irma Haney wrote: ===

Thanks for your response. I will try your suggestionto see what happens. I'll let everyone know the out come.

=== At 16 AUG 1999 08:47PM Warren wrote: ===

It's not the size of the file that matters, but the number of records and length of the keys.You can have a file with 32768 null (empty) records with one-byte keys and QUICKDEX will blow up. 13108 null records with 4-byte keys will blow up, etc.

=== At 17 AUG 1999 10:44AM Dave Bennett wrote: ===

Your correct quickdexs cannot be larger than 64k because the ordered list exists as one record in Arev. This list is updated before the saving of each record. Therefore if the next save list is going beyond 64k the user will receive the message and the record will not be saved. Therefore that cannot be the problem.

=== At 17 AUG 1999 02:35PM Warren wrote: ===

The %RECORDS% gets updated whenever a record is written to a file with quick/rightdex. It also gets checked/updated whenever a SELECT is performed on a file with quick/rightdex.Here's one scenario:%RECORDS% item is close to 64K. A record is added to the file. %RECORDS% is read into memory by QUICKDEX.MFS and the new keys are inserted/appended to the variable triggering the varible exceeds maximum length error. The record gets written to the file, but %RECORDS% is not updated on disk. The next time a record is added or a SELECT is performed on the file %RECORDS% will be updated in memory causing the error to occur again.That's why I suggested calculating the %RECORDS% size with the formula=(No. of Records * (len(@ID)+1)) - 1). If it is over 32K you should seriously consider removing quick/rightdex from the file. Quick/Rightdex is best suited for static lookup tables rather than dynamic constantly growing tables.It is a simple matter to remove quickdex from a file, taking less than 30 seconds. Adding it back on probably won't take more than 15 minutes on a very slow network and workstation. Thirty seconds to fifteen minutes of time to eliminate one possible cause of the problem seems worth the hours, days, months of hair pulling and fighting with the hardware/network people looking for a network/workstation glitch to me.

=== At 17 AUG 1999 06:57PM Victor Engel wrote: ===

The %RECORDS% gets updated whenever a record is written to a file with quick/rightdex. It also gets checked/updated whenever a SELECT is performed on a file with quick/rightdex.If this is true it is news to me. In my experience, %RECORDS% is updated immediately upon writing a record. %RECORDS%, rather than being updated at the time of a SELECT is, in fact read in order to resolve the select. That is why a select on a file with a quickdex/rightdex is already sorted.Here's one scenario: %RECORDS% item is close to 64K. A record is added to the file. %RECORDS% is read into memory by QUICKDEX.MFS and the new keys are inserted/appended to the variable triggering the varible exceeds maximum length error. The record gets written to the file, but %RECORDS% is not updated on disk. The next time a record is added or a SELECT is performed on the file %RECORDS% will be updated in memory causing the error to occur again.I don't think this is not a possible scenario since %RECORDS% is updated immediately.

=== At 19 AUG 1999 09:24AM Irma Haney wrote: ===

I really appreciate everyone's input. I started with oneof the suggestions made online and so far so good.No quickdex errors in a couple of days. First time in along time.WHAT I DID:I needed to move data to another volume so I moved ourusers data like MS Office97 documents and ect. and mappedworkstations to a drive other than the one usedby our Revelation application. Just changing the drivemapping may have worked but it just so happened I needed to reallocated space and it was the perfect time to do so.Wsers toggle all day long from MS Office to Revelationswith no problem so far.Thanks!

=== At 19 AUG 1999 09:25AM Irma Haney wrote: ===

I really appreciate everyone's input. I started with oneof the suggestions made online and so far so good.No quickdex errors in a couple of days. First time in along time.WHAT I DID:I needed to move data to another volume so I moved ourusers data like MS Office97 documents and ect. and mappedworkstations to a drive other than the one usedby our Revelation application. Just changing the drivemapping may have worked but it just so happened I needed to reallocated space and it was the perfect time to do so.Wsers toggle all day long from MS Office to Revelationswith no problem so far.Thanks!

View this thread on the forum...