Subject: REVTF file not available.

Background:

Transaction Processing is no longer supported in AREV 3.12. Most of the

Transaction Processing software still works however, and we at HELM have

got it working by writing programs to fill in the gaps.

Anyone unfamiliar to Transaction Processing will not understand what our

problem is fully but may be able to suggest a cause so please read on.

Very briefly, you switch Transaction Processing on and all updates are

stored until you either Commit the updates or abandon them in an action

called Rollback. Commit is the action of moving the records from their

temporary storage areas to the target files. This is used in the situation

when a batch of updates must either all be done or none be done, some being

done being a disaster. The batch of updates is called a Transaction. The

temporary storage areas are AREV files starting with "REVTF_", defined in

the TRANSACT volume.

Problem - Error SQL-208:

Transaction Processing worked very successfully for a number of months

before we hit our problem. For no reason we can think of we get the

SQL-208 message that follows on a random basis.

–SQL-208————————————————————

                The transaction table

"REVTF_CONTRIBUTION_NZPP_0060972537B0_11194116NOV1995"

                  is not available

                      «  OK  »

---

This is almost always during the Commit of the updates to the target files.

The result of this is that no copying from this file to the target file

occurs and part of the Transaction fails to occur. Additionally, as it is

an OK message, it hangs the process. There is no way out if you crash the

system as part of the Commit has been done. As a lot of processing is done

in the evenings, the machines being unattended, the expected volume of

updating fails to occur and they get behind.

It seems to be seasonal. They will have no trouble for weeks, then it will

happen several times a day.

The hit rate is far less than one in a thousand times during the "season"

but our client uses Transaction Processing well over two thousand times a

day so the incidence is high.

Possible causes that have been discounted:

· Since it did not occur in the first few months and no changes to AREV

have been made since system-start (we started with 3.12) it does not appear

to be a fault in AREV. Also we have not made any adjustments to parameters

at system level.

· The suggestion that the maximum number of files for the

machine is exceed is discounted because we have numerous examples of a

process running happily for an hour or more before hitting SQL-208. A

process loops several hundred times, sometimes two thousand times, before a

file which has been used every time suddenly becomes unavailable.

Transaction Processing is used each time through the loop. Statistical

analysis of a few samples showed that it was not after the n?th time

through the loop. It has been noted on four of the twelve machines that

our client uses for AREV. This is not necessarily indicative of faults on

these four, as the processes which use Transaction Processing are run by

only some of the staff and the processes which involve bulk running with

Transaction Processing are run by even fewer.

· It is not obviously

connected to changes in the Novell NetWare software, although moving to

version 4.1 coincided with an increased higher level of incidence. (We're

using NLM 1.12 and Windows 3.1x)

· The fact that the message is an SQL message is interesting as Transaction

Processing is clearly handled partly by SQL programs. We have no

experience of SQL so are not aware of any hidden meaning in the "not

available" expression. A pure guess would be that the network suddenly

lied that the file was read only but it seems unlikely. We cannot think

what else it would be.

"Not available" can mean that a DOS file is missing when you open a file

or that part of it, such as the index, has an incorrect internal AREV name.

These are the only two cases we can think of which issue this expression

and it cannot be either of them as the file is already open and well used.

HELP, Please:

=============

Any ideas would be gratefully received as we have decided to perform the

Commit via special coding, which will slow down the processing. We want to

go back to using the AREV programs if possible.

Just grasping at straws here:

That table name is very large. You might want to check the display length for the key field of any table using that as a key. The dictionaries for SYSTABLES and REVMEDIA come to mind, although I really think this should not be a factor.

What sort of indexing processes do you have set up? Ensure all your volume labels are unique and that they are consistent within a volume. I'm talking about Arev volumes here.

Make sure all users are using the same language set and that it is the same as the one the indexer is using.

These things probably will get you nowhere, but at least it's something. I've never used transaction processing in Arev, so I don't have any more ideas.

View this thread on the forum...