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 04 JUL 1999 06:35:14AM HelenF. wrote:

I have a very large client who is running OI 3.7 with an NLM 1.5 and a dedicated indexer. One vital report they run was not returning accurate data. After rebuilding the indexes on the table involved, the report was correct. How can the indexes be out of wack with this set up? How can I prevent this? It is critical that these reports be accurate. Any help would be greatly appreciated

Thanks


At 04 JUL 1999 10:24AM akaplan@sprezzatura.com - [url=http://www.sprezzatura.com]Sprezzatura Group[/url] wrote:

There are many reasons. One is an error occured on saves before the index transactions were finished. Another was a GFE in the indexes was fixed and indexes were not rebuilt. Another is the index is on a symbolic. Another is there are so many index transactions, the indexer did not have time to finish the processes. Another was someone decided to be slick and bypassed the normal write with direct rtp57 calls.

akaplan@sprezzatura.com

Sprezzatura Group

www.sprezzatura.com_zz.jpg


At 08 JUL 1999 09:24AM W van Monsjou wrote:

Thank you Aaron for responding to this problem. Of the possible reasons you pointed out, 2 listed below may be the cause. If either of these reasons are the case what can be done if anything to rectify the problem. The table contains 65,000 records and has 7 indexed fields, only one field (a date field) is corrupting.

1. One is an error occurred on saves before the index transactions were finished.

2. Another is there are so many index transactions, the indexer did not have time to finish the processes.


At 09 JUL 1999 12:42PM akaplan@sprezzatura.com - [url=http://www.sprezzatura.com]Sprezzatura Group[/url] wrote:

Only real way to tell if the indexes have not had time to update is check the transaction files and see if there are still transactions there. If you have large keys, it will take some extra time to update the indexes since the trees will take a long time to balance. Balance is the B in BTREE, a Balanced Tree index.

akaplan@sprezzatura.com

Sprezzatura Group

www.sprezzatura.com_zz.jpg


At 09 JUL 1999 03:46PM Cameron Revelation wrote:

Aaron,

… since the trees will take a long time to balance. Balance is the B in BTREE, a Balanced Tree index.

… and sometimes are confused with binary trees, which are not typically balanced, and to make it even more confusing, an rb-tree (red/black) is a BTREE implemented as a binary tree (in other words a balanced binary tree).

Almost all databases use a BTREE structure for storing data because it is very efficient for accessing ordered sets of information from disk with relatively small memory requirements.

Cameron Purdy

Revelation Software


At 21 JUL 1999 01:22PM w wrote:

I certainly won't forget the meaning of a BTREE index!

Balance is the B in BTREE, a Balanced Tree index.

Or perhaps the index file is not being locked correctly and the 0 record is being overwritten or corrupted by


At 21 JUL 1999 01:31PM W van Monsjou, Megamation Systems Inc. wrote:

I certainly won't forget the meaning of a BTREE index!

Balance is the B in BTREE, a Balanced Tree index.

Or perhaps the index file is not being locked correctly and the 0 record is being overwritten or corrupted.

The Network/Client configuration is:

Open Insight Version - 3.7

Number of Users - 256

Vendor Type - IPX/Netware Multi-user Driver ver 1.5a

Novell Version - 3.12

Patches applied - 312Y2K-P2, IPX660, LIB312B, LIB312C, STRTL6, STRTL7

Clients - Win 95

  1. Novell Internetware client 2.2.0
  1. Netware client 3.01

View this thread on the forum...

  • third_party_content/community/commentary/forums_nonworks/9b046a7c63688634852567a4003a2866.txt
  • Last modified: 2023/12/28 07:40
  • by 127.0.0.1