Here is a web page that has some more details on my table corruption problems:

http://members.xoom.com/DynaSoft1/oi.html

To me it looks like an OI bug. Revelation claims it must be something I have done. Anyway, here are the details. If someone can see something wrong with what I've done that'd be great as it would much easier to fix than an OI bug and I'd really like to finish this project. Thanks.

- Greg (dynasoft@home.com)

Greg,

Silly question time: Have you looked at your corrupted table with something else than Table Browser? Table Browser is known to be buggy. I don't think it's supported any more.

I'm not saying your table isn't corrupted, but at least it's best to use tools that can be trusted. In your case I think I would try and compare all the records of DICT.PERSON2 and DICT.PERSON3 with System Editor and look for differences. (Your Table Builder screen dumps don't show everything about your table definitions.) Perhaps also make a couple of quick data entry windows with Form Designer to look at the data.

- Oystein -

oystein.reigem@hit.uib.no

Thanks for the reply, Oystein. The data looks the same in the form (still corrupted) that I have created for the table. What should I look at in the system editor for the "DICT" files? I'm not sure what you are suggesting. The product is relatively new to me. Thanks.

- Greg

Greg,

The data looks the same in the form (still corrupted) that I have created for the table.

The data themselves are in the data table (e.g, PERSON2). Each data record contains a string of field values delimited with @FM. But the data table knows nothing about which fields it contains. A data record is just a dumb delimited string. How to interpret the data is the responsibility of the dictionary (DICT.PERSON2). The dictionary knows the names of the fields, their types, which order they occur in, if they're single- or multivalued, etc. (You might know all this of course. I apologize.)

So what is corrupted - the data table or the dictionary?

Check some records in the data tables with the System Editor (File | Open Record). System Editor shows each field value on a separate line - you don't see the @FMs. If the same record in PERSON2 and PERSON3 look different the corruption is in the data table.

If they're identical inspect the dictionary records with System Editor.

What should I look at in the system editor for the "DICT" files?

I don't really know. Just any difference. But even if you do spot differences you might not be able to find what caused them…

From your Table Builder screen dumps I can only see one trivial difference, in the delimiters of the BUS_PHONE_XREF formula.

But perhaps it's not trivial after all. Because the delimiters in the the PERSON3 version of BUS_PHONE_XREF are non-standard (\202D2C40282923\). I don't say there's anything wrong with them. But you cannot have got them from Database Manager, which is the standard tool for making indexes, including XREF indexes, and therefore the XREF symbolic fields and their formulas. Database Manager offers \20FDFCFB2C2E2D5C\, so \40282923\ must have got there in a different way. I know that the PERSON3 table seems to be OK, but if somebody edited DICT.PERSON3 they might have edited DICT.PERSON2 too. And messed up.

But since I'm still using 3.61 the explanation might also be that you have 3.7x and that Revelation finally improved the Database Manager's Add Cross Reference Index interface to allow for user-defined delimiters.

- Oystein -

Thanks for your response again Oystein. I'm just back from vacation thus the delay in my response.

I checked the records of my tables in the system editor. Looking at a specific record for "PERSON2" in the system editor, what is listed is "46 29 37 2983" instead of all of the values for person name, adress, etc. The same record in the person3 table looks fine and all of the fields are listed correctly so I guess it is the table that is corrupted.

You mentioned that the field definition for the "bus_phone_xref" looked funny for the person3 table. However, this was the table that was not corrupted. The "bus_phone_xref" field for the corrupted person2 table was defined as "CALL XREF({BUS_PHONE},\20\,"","1")" which was the default value that OI gave it when it created the index. The way it was defined in the person3 table was just copied from the original arev table defintion. Can't I use those definitions anymore?

Anyway, would you have any more suggestions at what to look at? Thanks again.

- Greg

Thanks for your response again Oystein. I'm just back from vacation thus the delay in my response.

I checked the records of my tables in the system editor. Looking at a specific record for "PERSON2" in the system editor, what is listed is "46 29 37 2983" instead of all of the values for person name, address, etc. The same record in the person3 table looks fine and all of the fields are listed correctly so I guess it is the table that is corrupted.

You mentioned that the field definition for the "bus_phone_xref" looked funny for the person3 table. However, this was the table that was not corrupted. The "bus_phone_xref" field for the corrupted person2 table was defined as "CALL XREF({BUS_PHONE},\20\,"","1")" which was the default value that OI gave it when it created the index. The way it was defined in the person3 table was just copied from the original arev table defintion. Can't I use those definitions anymore?

Anyway, would you have any more suggestions at what to look at? Thanks again.

- Greg

Here is some more info. For the uncorrupted table a typical !person.name_xref record looks as follows:

2

NAME_XREFTERROUX NAME_XREFTANJU

TANK-SHANKS TANNE TANNER TANNOCK TANSEY TANSKI TANSLEY TAO TAPP TAPSAY TARA TARCHUK TARDIF TARIK TARIQ TARKO TARNAWSKI TARNOWSKI TARR TARRAS TASCHUK TASNIM TASSEY TATEBE TATHAM TATTRIE TAUCHNER TAUN TAUSCHER TAUTFEST TAVARES TAVERNER TAY TAYFEL TAYLOR TAYLOR-HAMILTON TEARNEY TEBBUTT TECHNICAL TECHNOLOGY TED TEDD TEDDI

6842 17512 12403 14976 2404 9009 16994 9905 18228 14539 17138 17164 11602 15227 15459 11137 5068 16674 4052 12081 16968 8674 3443…. etc.

For the corrupted table the !person.name_xref made no sense at all as there is no references to names but I suppose that's no surprise as the only thing that wasn't trashed in the table was the record key. Some of it is as follows:

1006

2665

4001 6668

4001 6668 1506

7017

9394 9151 11895

9394 9151 11895 11893

4471

9394 9635 9393

9394 9635 9393 11893

12648

12272

12272 11903

10538

16782 12019 12005 12006 8857 11997

16782 12019 12005 12006 8857 11997 12003

3399

16799 16782 16893 16903 16788 8861 16895 16905 16781 16792 17021 16894 16904 16886 16914 16783 11165

16799 16782 16893 16903 16788 8861 16895 16905 16781 16792 17021 16894 16904 16886 16914 16783 11165 12003

18035

19470

19470 19123

etc.

Greg,

I checked the records of my tables in the system editor. Looking at a specific record for "PERSON2" in the system editor, what is listed is "46 29 37 2983" instead of all of the values for person name, address, etc. The same record in the person3 table looks fine and all of the fields are listed correctly so I guess it is the table that is corrupted.

Looks like it.

You mentioned that the field definition for the "bus_phone_xref" looked funny for the person3 table. However, this was the table that was not corrupted. The "bus_phone_xref" field for the corrupted person2 table was defined as "CALL XREF({BUS_PHONE},\20\,"","1")" which was the default value that OI gave it when it created the index. The way it was defined in the person3 table was just copied from the original arev table defintion. Can't I use those definitions anymore?

You can probably use them.

I can only think of the following possible pitfalls with using an old definition:

- If you for some reason had 8-bit data back in Arev and therefore perhaps also 8-bit characters as delimiters (well, system delimiters are allowed of course) you would have to change them, because those characters will have different integer (hex) values in the Windows world. But \40\, \28\, \29\ and \23\ are all 7-bit, being @, (, ) and #.

- OI doesn't accept spaces in the formula (except of course between "CALL" and "XREF"). For all I know it's the same with Arev. I mention it just in case.

For the uncorrupted table a typical !person.name_xref record looks as follows: 2 NAME_XREFTERROUX NAME_XREFTANJU TANK-SHANKS TANNE TANNER TANNOCK TANSEY TANSKI TANSLEY TAO TAPP TAPSAY TARA TARCHUK TARDIF TARIK TARIQ TARKO TARNAWSKI TARNOWSKI TARR TARRAS TASCHUK TASNIM TASSEY TATEBE TATHAM TATTRIE TAUCHNER TAUN TAUSCHER TAUTFEST TAVARES TAVERNER TAY TAYFEL TAYLOR TAYLOR-HAMILTON TEARNEY TEBBUTT TECHNICAL TECHNOLOGY TED TEDD TEDDI 6842 17512 12403 14976 2404 9009 16994 9905 18228 14539 17138 17164 11602 15227 15459 11137 5068 16674 4052 12081 16968 8674 3443…. etc.

Looks normal to me.

For the corrupted table the !person.name_xref made no sense at all as there is no references to names but I suppose that's no surprise as the only thing that wasn't trashed in the table was the record key.

Agree.

So could there be something wrong with your COPY_TABLE_DATA subroutine? Here are some suggestions (in the wrong order, perhaps):

(3) Try to run it again. Make a backup of everything first so you can go back and check things if necessary. Then delete all rows in PERSON2 and run it again. I know the subroutine is supposed to delete all rows, but to be on the safe side do it by hand in Sys Ed's Exec Line, either with run Clear_Table "PERSON2" or run Delete_Row "PERSON2", "*". And for good measure check with Sys Ed afterwards (File | Open Row) if it really was cleared (remember to Refresh) (I don't know why it should fail really, but it's best to do this in careful steps).

(2) But perhaps you should first check if PERSON2 contains only rouge rows, or if there is a mix. Let's say your table for some reason contained garbage from an earlier experiment. And your latest import was successful except the Delete_Row for some other (?) reason failed.

(1) I haven't tried to run your COPY_TABLE_DATA subroutine myself. But I have some comments about your coding:

- Replace Copy_Row with simple read and write statements. You'll have to do an open first too. See http://www.revelation.com/WEBSITE/DISCUSS.NSF/f12696d31000b22a8525652b00831bb2/78ade6bd762525bf8525671e005735f8?OpenDocument.

- Add some error checking. After read and write and select you can check the @File.Error variable (see under System Variables in online docs). After functions doing table stuff (e.g if you keep Delete_Row) you can check with Get_Status. This is how I do it:

declare function Get_Status

declare subroutine Set_Status

<code>

.......
Set_Status(0)
...function call...
if Get_Status(ErrCodes) then
...error handling...
end
Set_Status(0)

</code>

- Oystein -

oystein.reigem@hit.uib.no

View this thread on the forum...