Please refer to my message dated 10/2/98.

 After checking everything suggested (i.e., key field length, trailing delimiters,

and removing all MFSs except the SI.MFS), I then deleted the table and

dictionary and recreated both. I rebuilt the indexes and tested saving a

new record which updated correctly. Immediately after the save I checked the

!TABLE 0 record and the data was there. I thought the problem was

resolved until today when the creation of some new records did not

update. I saved another test record and nothing was written to the

!TABLE 0 record.

 One thing that has caught my attention this time,  however, is the

!TABLE *INDEXES record. I'm assuming the purpose of this record is

to store the fields indexed on a specific table. On the tables where the

indexing is updating correctly the record looks like this:

FIELD1²FIELD2²FIELD3

But, on the table with the indexing problem the same record looks like

this:

1²FIELD1²FIELD2²FIELD3²FIELD4²FIELD5 What is the 1? And, does the key field need to be listed first?

Thank you all for your earlier assistance and any further help you can

can provide will be greatly appreciated as well.

I would run a program to check all dictionary and table Ids to make sure they contain no delimiters. Have a character GT CHAR(240) can cause just the type if *INDEXES problem you're seeing. Also, check the data/dict files for a null ID existing; even a null ID can have a 1 in field 6 if it's in the DICT, thus causing that to index.

Send your email address, and I'll send my validator programs.

Larry Wilson

[email protected]

http://members.tripod.com/rehabsw (NEW homepage, Frontpage exten.)

The **1 is some sort of self-refercing relational used for updating symbolic indexes. Not sure what it's doing there, but I'll bet you have some errant data in a dictonary record.

[email protected]

Sprezzatura, Inc.

World Leaders in all things RevSoft

View this thread on the forum...