During the write event (CALL Forward Event) I get the following message on a table that is the source table of a relational index. This is happening on a new index as well as one I have had running successfully for some time.

ENG0010 $! line 1 Variable has not been assigned a value.

(In case this forum messes up the two characters after the ENG0010, they are a dollar sign followed immediately by an explantion mark / point). This $! also appears in the title bar of the debugger, which seems to indicate it is the name of the currently running program???

If I remove the relational index, the error goes away. If I rebuild the index, the index updates correctly.

The call stack contains the following information

$!~RTP57@vm~000000000133DATAVOL\MYDATA\REV69035.LK

CALCULATEX

SI.MFS

FORMUPDATE

SEMANTICLOGICLAYER

$$$SYSPROG*WRITE.WINDOW.OIWIN*

RUN_EVENT

SEND_EVENT

In the first line above, substitute the ~ tilde symbol with a solid block character that possibly looks like a tab character. The @vm is actually the y with the wiggle above.

Anyone have any ideas? I'm stumped.

TIA

Robert Lee

The program that's breaking is the generated ! code used by the system. You're not running this on a symbolic are you?

That code is pretty rock solid. You can generate the source code for this module by creating a !! record in the !FILE, deleting the ! record then reattching the file. When the file is opened, the system will regerate the ! record and place the source in the !! record. You can examine the !! record for problems, or even compile and execute it. The system calls the ! record as a dictionary item, hence the calcalyst call in the return stack.

The Sprezzatura Group

World Leaders in all things RevSoft

Hi Sprezz

Thanks for your response.

]You're not running this on a symbolic are you?

No. This is a field called GROUP_1 in a table called CLIENTS which is being relationally indexed back to a table called CLIENT_GROUPS_1 which should contain a list of clients who belong to each group. I do have a symbolic called GROUP_1_DESCRIPTION, but that is for display purposes only. In fact, it is not being currently used.

I followed your instructions and found everything as you said. I don't doubt the code is rock solid. I do notice that that error occurs on line 1. Assumming we don't count *comments, COMMON, EQU & DECLARE statements as lines, the first line is

POS=6 + @ANS 1, 5

* @ANS contains SI.MFS file handle, parse into local variables.

Does this mean that @ANS is unassigned???

My biggest concern is not so much the new index that I am trying to build, but rather that the one that has been working for months now comes up with the same error too. So it seems the problem relates to Relational Indexes in general, not one in particular. I have also tried GROUP_2 and GROUP_3 to no avail.

Any more thoughts??

Robert Lee

No Robert - the ! code calculates ALL symbolic indexes and will always be breaking on line 1 as this is a dictionary compilation and thus has no linemarks.

So how many symbolic indexes do you have, if any?

The Sprezzatura Group

World Leaders in all things RevSoft

Ok. I assumed you were asking about symbolic Relational Indexes. The Client table also has a BTREE index based on a field called NAME which is a symbolic concatenation SURNAME, FIRST_NAME.

I removed that BTREE index and the original relational index (where the destination is the CLIENT table) now works. Also the ENG0010 error goes away when I perform a WRITE on the Client table. So we now seem to be on the trail of the problem.

However, the relational index (CLIENTS.GROUP_1) is not updating the destination (CLIENT_GROUPS_1.CLIENT_NOS). After the Call Forward_Event on the WRITE event, I have a call to UPDATE_INDEX('CLIENTS', '', False$). Only if I rebuild the index does it update.

Of course I would like a BTREE index on the symbolic. Is this not possible? Is there another way to accomplish the same?

Thanks again Sprezz. You guys are tops.

BTREEs on symbolics are fine - there must be a bug in the formula somehow… sorry .

We've seen the index not updating without a rebuild on a client site and spent some time trying to track it down. Hopefully the US Sprezzie involved will be able to shed light!

The Sprezzatura Group

World Leaders in all things RevSoft

Bug in the symbolic huh? I'll buy you a XXXX if you find a bug in this code .

@ANS={SURNAME} : ', ' : {FIRST_NAME}

Best of luck…

Rob

Rob ..

Try this:

XX={SURNAME}

YY={FIRST_NAME}

@ANS=XX:', ':YY

Each braces call resets @ANS on return. I think the @ANS might contain only the First_Name variable. By using static variables for braces call and explicitly resetting @ANS, you might solve the problem

Just a thought..

Don Miller

C3 Inc.

Actually, depends on the nature of the {SURNAME} and {FIRST_NAME} symbolics.

If they are symbolics themselves, well, that's a possibility.

If they are MV fields and marked as SV fields, then the @VMs could throw things off.

If they are real fields, then change to

@ANS=@RECORD : ", " : @RECORD

The Sprezzatura Group

World Leaders in all things RevSoft

Just doublechecking - this symbolic is in REV69035.LK not the other file involved in the indexing?

The Sprezzatura Group

World Leaders in all things RevSoft

This is where things start to get hairy without being able to see your system.

Relational indexes aren't like btrees (and by extension, cross references, which are just btree indexes on a symbolic).

Btree indexes place transactions into the !file for updates later. These can be the update_index calls, or index.flush calls or background indexing (it all goes through the same code).

Relational indexes should be updated immediately. What will happen is the system will attempt to lock the destination record. I think it gives it 20 tries, give or take. If the lock is successful, RELATER will update the destination record with the new value. If the lock is unsuccessful, RELATER will place the transaction into the !FILE. That's why a !FILE is created for the relational index, in the destination only. The source doesn't really have much to do with it after the write.

So, as to the question as to why the record isn't being updated, we need to determine if the instant update is failing or if the destination is locked and the !FILE based update is failing.

One thing to look at is to see if the protected flag in the destination record is set. It could be that in whatever version of OI you're using it's not ignoring that flag and the system is clearing out the update.

The Sprezzatura Group

World Leaders in all things RevSoft

Firstly, NAME is displayed in the Popup and is correct.

SURNAME and FIRST_NAME are single value data fields.

I changed the code to:

@ANS=@RECORD : ", " : @RECORD

and have noticed no change.

The REV69035.LK is actully the !CLIENTS file.

So, to reiterate:

1. There is a BTREE index based on a symbolic field called NAME

2. There is a transaction file which is the source file of a relational index to CLIENTS. Since removing the BTREE index on clients and readding it, this now works. (Before it was crashing with the original message I posted in this thread).

3. I am trying to create a new relational index where CLIENT is the source table and CLIENT_GROUP_1 is the destination table.

4. Since removing the BTREE index on clients and readding it, this no longer crashes, but it only updates the destination when I rebuild (rather than update) the index.

I have recently been swatting up on MFS. They talk about the importance of having them in the right order if multiple MFSs are involved. Has anyone else successfully used a table which has a symbolic BTREE index, is the destination of one relational index and the source of another relational index?

Robert Lee

View this thread on the forum...