Anybody got a function that just rebuilds a relational index? Source, please.

What I need it for?

I have this static table related to itself. Since it's static a standalone function will do.

If the function doesn't handle a table related to itself I can make the necessary modifications myself.

The standard relational indexing fails on my table because I have different keys that look equal, like "12.3" and "12.30". I don't expect the function you supply to be any different, but again I can modify the function to suit my needs. (The way I use the table these keys won't cause me any other problems.)

Talking about modifications: There is yet another feature of the standard relational indexing I'd like to get rid of: When the source field contains a value that is not a key, a new row with this value as a key is added to the table. I'd rather get an error message.

- Oystein -

Oystein ..

Below is a snippet of "old code" from Arev 2.12 which I use to rebuild relational indexes:

* Next the Relational indexes ….

* note: RELAT_VAR contains a pointer to the relational entries in

* the DICT of the file

* RELAT_INFO is the indexing information for that DICT element

IF RELAT_VAR THEN

 RCNT=COUNT(RELAT_VAR, @FM) + 1

 CONVERT '*' TO @VM IN RELAT_INFO

 FOR Z=1 TO RCNT

    R_FIELD=RELAT_VAR ;* relational field

    REL_TABLE=RELAT_INFO ;* table indexed into

    REL_FIELD=RELAT_INFO ;* target field

    SORT_ORDER=RELAT_INFO;* sort order

    OPEN 'DICT.':FILE_NAME TO DICT_FILE ELSE

       MSG('Unable to open dictionary','','','')

       RETURN

    END

    READ OLD_DICT_REC FROM DICT_FILE, R_FIELD ELSE

       MSG('Unable to read dictionary record','','','')

       RETURN

    END

    NEW_DICT_REC=OLD_DICT_REC

    NEW_DICT_REC=REL_TABLE:'*':REL_FIELD:'*':SORT_ORDER

    WRITE NEW_DICT_REC ON DICT_FILE, R_FIELD ELSE

       MSG('Unable to write dictionary record','','','')

       RETURN

   END

• if you need the source to MAKE.INDEX let me know. I'll have to e-mail it to you

   MAKE.INDEX(FILE_NAME, R_FIELD, OLD_DICT_REC, NEW_DICT_REC)

• I don't think that INDEX.FLUSH works in OI, but I think there's an acceptable substitute

   INDEX.FLUSH(FILE_NAME, REL_TABLE:'*':REL_FIELD:'*':SORT_ORDER)

 NEXT Z

END

The other option would be to temporarily remove the MFS from the static tables, and remove the protection flag in the associated dicts and then manually rebuild the index your way. Then put the MFS and dict fixes back. If it's static it shouldn't happen too often. In this way your data that looks the same can be handled by strings and numeric evaluation. The problem is always in a 'AR' sort order unless you do that too in your code. Unfortunately "1.10" and "1.1" don't evaluate properly with system routines.

HTH

Don Miller

I realize I didn't describe well enough what I need. I want source code that emulates the process of rebuilding a relational index: something that goes through the source table, reads each row, and updates the target field of the target table. And since the standard relational indexing can't handle the data I need indexed, I expect to modify that source a bit before I can use it. For the same reason the resulting index should be a secret - no mention of it in the dicts. I don't want the real relational indexing ever to kick in. My source table will be static; I as the developer will be the only one to change it. And when I change it I will make sure to rerun the indexing process afterwards. With the code I get from you (modified a bit by me). But I realize I might now have used almost as long time describing my needs as it would take me to write the code myself.

- Oystein -

Oystein,

…I want source code that emulates the process of rebuilding a relational index: something that goes through the source table, reads each row, and updates the target field of the target table. And since the standard relational indexing can't handle the data I need indexed, I expect to modify that source a bit before I can use it… I don't want the real relational indexing ever to kick in….

I look through some of my Arev documentation and a routine called RELATER. I'v not used it personally, however, it may bring you one step closer to what you want with no code or minimize your coding. I also see that a function with the same name exists in OI (see SYSOBJ). If the program in OI is the same as in AREV then it may help if the souce code was released. Don't know if you have heard of RELATER or not, but according to the document it says:

Use RELATER to perform relational transactions when you cannot or do not want to take advantage of AREV secondary indexing… RELATER neither requires nor create a relational index….

Hope this helps. Maybe someone else will jump-in and offer some experts comments on RELATER. For example, is the RELATER in AREV the same as in OI? If not, can it be easily modified? Will source code for this routine be available as part of the Collaborative program?

I might now have used almost as long time describing my needs as it would take me to write the code myself.

If that were only true )

Good Morning,

Ray

[email protected] onmouseover=window.status=imagine … ;return(true)"

Symmetry Info

Ray Chan ~ Symmetry Info

Ray,

Thanks. I'll sit tight and wait for more info on RELATER.

- Oystein -

View this thread on the forum...