From BRTT
dbfixids is not updating the prefor field in my event table, but does update the values for orid in the origin table (and evid in both event and origin tables).
The command lines attempted:
% dbfixids mydb arid % dbfixids mydb orid % dbfixids mydb evid
The arrival table after dbfixids has updated arids. The origin table has updated orids and evids. The event table has updated evids but the prefor field was NOT updated with new evids. Thus the database is now corrupted.
From the dbfixids manpage we see that:
Generally, dbfixids works by renumbering the ids in the table which defines that id, then changing all the other tables which use that id by that same name to correspond to the new id values in the defining tables. However, in some cases, an id has a different name in another table. For instance, in the css3.0 database, orid is called prefor in the event table, and magid becomes mlid, mbid, and msid in the origin table. Special cases like these must be called out in the parameter file for dbfixids.
So the first thing to check is whether or not you can see dbfixids.pf. The default is $ANTELOPE/data/pf/dbfixids.pf and should be available if you have your PFPATH env variable set properly. In that parameter file, you want to verify that there is a section like this which explicitly states that prefor is an alias for orid:
css3.0 &Arr{ aliases &Arr{ orid prefor magid mbid msid mlid } }
The next step is to see if the descriptor file you are using for your input database matches the array listed in the dbfixids.pf:
% cat mydb # schema rt1.0:gme1.0 dbpath ./{mydb}:../dbmaster/{mydb}
Note that the schema in the descriptor file does not match the schema listed in the dbfixids.pf (there is a second schema listed). You need to add this "combined" schema to the dbfixids.pf file:
rt1.0:gme1.0 &Arr{ aliases &Arr{ orid prefor magid mbid msid mlid } }
Re-run dbfixids on the original db (you did back it up before messing with the ids didn't you?), and your prefor should be updated in the event table.