Our company is running an AREV (3.1) application on

a Novell 4.11 server. We use the NLM.

We have recently encountered a problem with an index

on a field. The field is a text field and contains a

book title. Users began getting messages that the

index was being updated at another station, usually due

to stations in indexing being hung. One message

indicated a particular title (longer than usual) was

causing the problem.

We rebuilt the index, and the particular title could now

be searched and found. However, titles beginning with

the last few letters of the alphabet (U-Z)were not found

when the index was searched. I rebuilt the index three

more times, with same results. The index rebuild does not

seem to take long enough to run (5-7 minutes) compared to

past rebuilds, but it has been a while.

Last April we had a similar problem, resulting in just one

"group" of titles missing from the index, titles

beginning with "Ma". At that time, after a few weeks, the

problem just disappeared (after an index rebuild).

We also have a cross reference index on the same field, it

works fine.

We have had problems with null ids and multivalued ids in

other files, so I checked for that.

Any suggestions? What should we be looking for?

Thanks to anyone who can help.

Tracy at ABC-Clio

Ensure that your record ID is longer than the longest value that will be indexed.

Curt,

I must be missing something.

The IDs in the file containing the records indexed are

5 or 6 characters in length. The data in the title

field that is indexed can range from 30 characters to

300 characters or more. The title that appeared to cause

our indexing problem has at least 300 characters.

Can I supply more information that would be helpful?

Thanks, Tracy

Starting with ARev 3.0, a program called IDX_SETS shipped with the product. This program is what handles a good chunk of the index retrival logic. The good part about this program is it's pretty fast. That's because it was written in assembler. The bad part is that it's written in assembler. With that, and to gain some speed, it makes a few assumptions about your data based on dictionary information.

The program assumes that keys will be about the same size as the space allocated for display in an RLIST program. So, just to cover itself, it adds 5 or 6 characters to that. Then, using the fixed length key, it can sort itself really quick. Trouble is, if the key is too big to fit in the fix length session, it just truncates it.

If this isn't clear enough, post back and I'll try to clarify a little further.

apk@sprezzatura.com

Sprezzatura, Inc.

Aaron,

Thanks for the explanation. That, along with a

response from compuserve, cleared up my

misunderstanding. However, as far as I can tell,

the defined length for the record IDs in this file

is larger than any ID in the file, and definitely

larger than the IDs for the records that are giving us

error messages. We tried rebuilding the indexes after

changing the ID length (just in case) and also changed

the data definition for the field in question from

VARCHAR(40) to VARCHAR(700) and VARCHAR(63556 -

or whatever the highest amount is). None of this made

any difference.

After one of the rebuilds, we got an error message about

a different title, which also was about 250 characters in

length, so the problem seems to be related to longer

pieces of text, but changes from time to time. However,

the titles that are not showing up in the index are still

the ones starting with "The Pop…" and greater.

Regardless of the letter the long title starts with.

This problem has shown up when users are inputting many

records per day. In this file, the data may stay fairly

static for weeks, then there are one or two weeks of

heavy data entry.

For now we have removed the Btree index on the book title

field, and users can access

records via a title search using a cross reference index.

We have Btree indexes on other fields in this file, they

are functioning fine currently.

Any other possibilities for fixing this index?

Tracy at ABC-Clio

The only real suggestion I have is that if you're not at 3.12, then upgrade to there. It might solve the problem.

You also might want to see if you've allocated enough EMS memory to the system. The ARev FAQ will have some information to help.

apk@sprezzatura.com

Sprezzatura, Inc.

Aaron, Thanks again for the suggestions.

]] if you're not at 3.12, then upgrade to there.

Due to other problems we have run into, related to Windows 95,

we are planning to upgrade to 3.12, ASAP. So maybe it will help.

]] see if you've allocated enough EMS memory to the system.

Due to same problems mentioned above, we have looked 

into this pretty thoroughly, so we think we are OK in

that area.

Tracy at ABC-Clio.

Tracy,

I too lost the last few letters of a large text index. Based on a misunderstanding of the 65K limit on indexes, I increased the number of excluded common words (the, a, corp., etc). Although I have since been assured that that couldn't have fixed the problem, the problem was fixed and stayed fixed.

Good luck

david

View this thread on the forum...