One of our clients is receiveing the error message "Line 1. B10 Variable has not been assigned a value. Zero used. '!' broke because a run time error was encountered"

They are using AREV 3.12 ( I think) with the WIN2k driver on XP clients.

The error is occurring when the program times out, instaed of returning the program to the log in screen.

Does anyone have any ideas why this might be happening and how I can fix it? Most files are routinely verified so no outstanding GFE's etc to the best of my knowledge.

Thanks in anticipation

Does the error message indicate the program name which is having the problem? Normally this message is caused by a logical programming error - perhaps a condition being met that was not anticipated or checked for.

The Sprezzatura Group

World leaders in all things RevSoft

Or a typo or misspelling of a variable name. Hopefully the source code is available to track down and fix the problem. Breaking at line 1 though isn't a good sign but it could be a system subroutine called without the proper antecedent variables set.

Displaying the Return Stack by typing "R" at the debug prompt could be helpful provided this is not a run time system or otherwise disabled through settings.

Once in a blue moon we see an error like that. If it's the same thing, we have to remove all of the indexes from the effected table. Then we have to delete the index table (at TCL run LISTMEDIA to make sure the table is gone). Then rebuild the indexes from scratch on the table. After that we're good to go.

I hope this helps.

Micahel Slack

Caroline,

A program breaks at line 1 when the symbol table was suppressed during the compilation. (In AREV, I always compiled my code this way.) Here, the offending program appears to be executing from the indexing process. This means that it is either an indexed symbolic dictionary or an indexing replace process or post process. Without knowing the program name, though, I can't go any farther.

Gerald

Thanks every one

"Once in a blue moon we see an error like that. If it's the same thing, we have to remove all of the indexes from the effected table. Then we have to delete the index table (at TCL run LISTMEDIA to make sure the table is gone). Then rebuild the indexes from scratch on the table. After that we're good to go."

This sounds more like what I think could be the problem but as the table is related to others I can't remove and rebuild the indexes in the usual way – any tips on how I go about that would be appreciated.

Carolyn,

Are you saying the table uses relational indexes instead of the usual btree indexes? Not that we have established that the error is in a symbolic indexed column, mind you.

Gerald

Yes I receive a message thats specifically says relational tables

I am still guessing about what is happening. Normally relational indexes are updated immediately during entry, and only btree indexes are updated by FLUSHINDEX. This is not an absolute rule, though. To test this out in AREV, press F5 to display the TCL window, and type FLUSHINDEX . Does the message appear? If so, write down the exact message.

I think that the error message will contain information to identify the table name and indexed column causing the problem. Then rebuild that index, and use FLUSHINDEX to see if the problem goes away. If not, post a VERY DETAILED description of the error messages you are getting so that someone can help.

Gerald

Thanks, FLUSHINDEX not a recognised word on our system for some reason and when I did FLUSH INDEX there was no response. I have managed to recreate the original error message when attempting to reindex - the error is FS259 the table "st_uoc" has relational indexes on it and the related table "st_oi*excel*17:44:44 13 Aug 1993" is not available or attached for updating information

FS259 the table "st_uoc" has relational indexes on it and the related table "st_outcome*excel*17:44:44 13 Aug 1993" is not available or attached for updating information

OK do you have any idea WHY this other table is missing? HAve paths changed recently or drives been remapped?

The Sprezzatura Group

World leaders in all things RevSoft

That is the truely weird thing because the st_outcome and st_oi tables are still there, I can access them to look up codes and categories within the tables. We have recently made some network changes but the mappings etc seem to be fine, we can access the software okay.

Are you using QuickAttach? Try removing QA.

FLUSHINDEX is in my util_bp file, meaning that I have added that command to the TCL options of my system. Sorry, I was thinking that AREV had the flush index command builtin. (Hey, it worked for me.)

The "st_oi*excel*17:44:44 13 Aug 1993" information from the error message represents the data tablename, application account, and volume label for posting the index updates. Clearly, the volume name in the index info hasn't changed since 1993. However, if there has been file maintenance which has renamed or relocated the "st_oi" table, then the table might still be attached for list and so forth, but it would be missing for index updates because the new volume label would no longer match the index maintenance info.

Here the problem seems to be that a relational index is maintained between a primary table in volume1 and a secondary table in volume2. Revelation has never supported moving relationally indexed tables for the reason explained above – the volume references cannot be resolved.

"recently made some network changes but the mappings etc seem to be fine"

By network changes did those changes require the arev files to be moved? If the arev files where moved outside of arev (not with an arev COPYTABLE command), I suspect that removing the relational index and recreating it (or them) will be required.

The arev COPYTABLE command does advertise the proper updating of relational indexes for v3.12 (the version we use) and only when the COPYTABLE is used with the (D) delete option, which deletes the source. I can confirm this works when all users are logged off (by bouncing the LH service) and the tables are small. Confirm this actually works by testing this on your network if you use the COPYTABLE for future moves!

Our client is reporting that when the B10 error comes up he is creating a new UOC to the database , it saves okay but does not appear in the F2 look up when search by code is executed by users, does anyone know what might be causing this to happen? Thankyou

Too many variables… we don't know what a UOC is, we don't know what mechanism populates the F2 etc etc. We'd strongly suggest you get somebody to remote into the client box and help investigate. you can find a list of companies here

The Sprezzatura Group

World leaders in all things RevSoft

View this thread on the forum...