When my OI 3.5 application opens, it attaches certain

data tables in another application, written in AREV 3.1

This is normally no problem, but one of my users is

reporting the following error message on startup:

Fatal Runtime Error

SYS1000:ERROR

Error loading program SORT.NAME

SORT.NAME is a symbolic field in a table called NAMES in

the AREV application. It is calculated using a stored

procedure, also called SORT.NAME

It seems that, when my OI application attaches the AREV

NAMES table on startup, it is attempting to update the

SORT.NAME index, resulting in an error because the program

SORT.NAME cannot be found. All other users of the same OI

application (with the same AREV attachments) are running fine.

The error occurs when processing something called CALCULATEX

in RTP27 (whatever that is). See a copy of the call stack

below.

It seems that the OI application should not be trying

to update the AREV application's indexes. Why is this

happening at logon, when no other processes are occurring

other than attaching tables? Why is only this user experiencing

the problem, and how can I solve it? All suggestions will be

appreciated.

Mark Glicksman

Glenside, PA

RTP27

$SORT.NAME

CALCULATEX

$!

CALCULATEX

SI.MFS

RELATER

F.INDEXER

REV_BGND_UPDATE

Mark,

I cannot tell you why this is happening only on that workstation, but you could copy the object code from AREV into OI.

Basically just copy $SORT.NAME from Arev's OBJECT table into OI's SYSOBJ table.

With this, the program will be found and executed from now on.

Thanks for your suggestion.

If I copy the SORT.NAME routine to SYSOBJ, does this mean that

the OI application will constantly be trying to update the index in the

AREV application? Won't that lead to conflicts if the AREV application tries to update the same index at the same time. Do AREV and OI "know" each what the other is doing at any given time?

Mark,

From either Arev's or OpenInsight's standpoint, it doesn't make a difference if the workstations are all running Arev (3.1 or later), OpenInsight, or a mixture. They all act the same when it comes to indexing. Just make sure that the drivers being used are the same (so that locking works).

Cameron Purdy

Revelation Software

Cameron,

OK, thanks. I will check to make certain that the drivers are the same.

Mark Glicksman

Glenside, PA

Cameron,

Another question - is there a way to prevent OI from updating the indexes on specific tables - in this case the AREV tables that are causing the problems?

Thanks,

Mark Glicksman

Glenside, PA

Mark,

I do not know an easy way.

Cameron Purdy

Revelation Software

Cameron,

]]Just make sure that the drivers being used are the

]]same (so that locking works).

The OI driver is set to All Networks Driver 1.1.1.0

The AREV application is using IPX Advanced Netware

(This is what is displayed when WHO is entered at TCL)

The AREV data files and executable are located on a

Novell server.

All the OI files are local.

How should the OI network driver be set?

Thanks,

Mark Glicksman

Glenside, PA

Mark,

I thought you said that these two systems were working with the same data files? Could you start over at the beginning again:

1. You have OI and Arev.

2. Based on #1, you need to determine if OI and Arev share any files.

3. If #2 is Yes then the drivers must be compatible, for example they must both run the LH/IPX driver or they must both run the LH/NPP (All Networks) driver.

4. If OI and Arev share indexed files then I suggest using a dedicated indexer on one or the other. (The only problem is if they share some indexed files, but then they both have indexed files that the other doesn't see … then which do you run the dedicated indexer on?)

Cameron Purdy

Revelation Software

Cameron,

OK, I will rehash.

The AREV application sees only it's own files. The AREV executable and the data files are on a Novell server and is accessed by a number of workstations.

AREV is running with a dedicated indexer.

The OI application sees some of the AREV application's files plus it's own set of files (all local). Some of the AREV application's files that OI sees are indexed. OI is running locally on one workstation only.

It appears that OI is trying to update one of the BTREE indexes, for a field called SORT.NAME and is running into an error because it doesn't have access to a stored procedure required to evaluate this symbolic field.

As far as I can tell from the suggestions received so far, I need to copy the required procedure from AREV to the SYSOBJ table in OI, and see that both are running the same network driver.

Have I got it right? I really appreciate your help.

Mark Glicksman

Glenside, PA

Mark,

Sounds like you have it right now.

Instead of manually checking each column, you can test for missing dependencies in a table T that has columns C1 and C2 and a row with the key 'V', from the command line:

run rlist "LIST T C1 C2 WITH @ID=V'", 1

Cameron Purdy

Revelation Software

Cameron,

OK, I will give it a go. Thanks again to you and Dave.

Mark Glicksman

Glenside, PA

View this thread on the forum...