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

Indexes, Definition of "*INDEXES" entry in !FILENAME (OpenInsight Specific)

At 22 DEC 1997 07:09:22PM Tom Horan wrote:

We have developed a benefit administration module that intergrates in Ceridian's CI product. Most of tha data has been normalized thru relational indexing. There are several tables, BENEFITS, DEPENDENTS, BENEFICIARY, HISTORY, DESIGNATIONS. The DEPENDENTS, BENEFICIARY, HISTORY, DESIGNATIONS tables are related using relational indexes. We use a file called BENEFITS_INDEX. The only purpose of this file is to contain the relaterd key to all the different files. This way the relational data is not stored in the primary data file BENEFITS.

Here's the question:

Why is the a !BENEFITS_INDEX file? This file does not have any indexes. Is one created since the following files have a relational index to the BENEFITS_INDEX file:

DEPENDENTS, BENEFICIARY, HISTORY, DESIGNATIONS. The DEPENDENTS, BENEFICIARY, HISTORY, DESIGNATIONS

What is the "*INDEXES" entry for. There is not one in !BENEFITS_INDEX file, should there be? How do I create this entry.

Note:

If I create a Btree Index on the BENEFITS_INDEX file a "*INDEXES" entry is added? Why?

Thanks for your help..

Tom Horan

BenSoft Inc.


At 23 DEC 1997 09:55AM John Duquette wrote:

Tom,

The *INDEXES record is the record in the ! file that stores which fields have indexes on them. The ! file is created because the dictionary of the destination table (which in your case is the BENEFITS_INDEX table) has an index flag placed on it as well.

I would not create a *INDEXES record.

John Revelation


At 23 DEC 1997 03:49PM Aaron Kaplan wrote:

The system is written so that relational indexes update immediately. However, the best laid plans of mice and database developers sometimes go awry (or a rye, with maybe some corned beef and a pickle, if you please) and the record is locked.

So, what the system does is create a rudamentary index structure to hold the pending transactions so they can be updated later. That's why the !file is there. The *index records are only needed for 'real' indexing, so it doesn't bother to create one. You'll see that in the source file, there is a *index record for the relational fields.

[email protected]

Sprezzatura Ltd

www.sprezzatura.com_zz.jpg


At 30 DEC 1997 12:05PM Tom Horan wrote:

John,

Thanks for the comment. I didn't create the *INDEXES record. How can I delete it?


At 30 DEC 1997 12:14PM Tom Horan wrote:

Aaron,

Thanks for the info. Is there a way to remove the *indexes record. Is it needed? It seems to be creating a problem for a customer how is upgrade from Ceridians 2.61 to 3.00 version (this is were Ceridian is upgrading OI to ver 3.12).

Thanks,

Tom


At 30 DEC 1997 04:45PM Aaron Kaplan wrote:

From 12-22:

What is the "*INDEXES" entry for. There is not one in !BENEFITS_INDEX file, should there be? How do I create this entry. Note: If I create a Btree Index on the BENEFITS_INDEX file a "*INDEXES" entry is added? Why?

From 12-30:

Thanks for the info. Is there a way to remove the *indexes record. Is it needed? It seems to be creating a problem for a customer how is upgrade from Ceridians 2.61 to 3.00 version (this is were Ceridian is upgrading OI to ver 3.12).

Well, I'm confused now. If you're just relating into a file, and have no other indexes on there, then there will not be a *INDEXES record.

  • If BENEFITS_INDEX is the destination table, there will not be *INDEXES record.
  • If BENEFITS_INDEX is the source table, there will be a *INDEXES record.
  • If there is any other type of index on BEFEFITS_INDEX (btree or xref) there will be a *INDEXES record.

Based on what you said, there should not be a *INDEXES record. Perhaps you left an index on when you were playing or did not properly clear off indexes. You might want to remove all the indexes to this file then re-add them.

[email protected]

Sprezzatura Ltd

www.sprezzatura.com_zz.jpg

View this thread on the forum...

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