Status: Verified
SYMPTOM(s):
Why the CRC's Won't Match after Dumping and Loading.
** CRC for <filn> does not match CRC in <procedure>. Try recompiling. (1896)
Field trigger rpos cannot be set directly. (3291)
FACT(s) (Environment):
Progress 8
Progress 7
Progress 6 starting from 6.2F
CAUSE:
Sometimes you cannot dump one database definition then load it into another and expect that Cyclic Redundancy Check (CRC) values match between the two. This process is likely to fail but it might work from time to time. Consequently Progress cannot guarantee or support the CRC in this context.
The following is a simplified example:
If you have a database where you delete a field, the field position in the metaschema ( RPOS i.e. the value of the _Field._field-rpos field ), as it is stored internally is going to change. If you have 4 fields, A, B, C and D, and delete the third field C, in place of the deleted field is a place holder. The last field still has a _Field._field-rpos = 4.
Before deletion:
1 2 3 4
+--------+--------+--------+--------+
| A | B | C | D |
+--------+--------+--------+--------+
After deletion:
s"> 1 2 3 4
+--------+--------+--------+--------+
| A | B | | D |
+--------+--------+--------+--------+
When you dump the .df from this database and load into a new database, the new database has no record of that deleted field. Although it contains 3 fields in the particular file, the last field has _Field._field-rpos = 3.
After loading into a new Database:
1 2 3
+--------+--------+--------+
| A | B | D |
+--------+--------+--------+
>
Sinc the _Field._field-rpos ( RPOS ) is one of the fields that is used to calculate the CRC value, you can see that the CRCs between these two databases differ.
This is only one of the cases where a dump of an entire .df from one database and a load into another database fails.
If dumping and loading works for you, and it might, it is successful due to luck. It is not a reliable method for making a copy of your database to use with the CRC.
You can view the fields in the metaschema that relate to the CRC. Some of them are listed below, but there are many others. The following example shows how to view the rpos and the order field, both of which are part of CRC:
Please replace customer with the appropriate table names.
for each _file where _file-name = "customer":
display _file-name _file-number.
for each _field of _file:
display _field-name
_field-rpos
_crc
_order.
end.
end.
This produces the following output (the sample is taken for a customer file in Sports database):
File-name File-number
customer 2
Fiel.d-Name _field-rpos CRC Order
Address 4 6143 40
Address2 5 6143 50
Balance 14 6143 140
City 6 6143 60
Comments 12 6143 180
Contact 10 6143 110
Country 8 6143 15
Credit-Limit 13 6143 130
Cust-Num  .; 2 6143 10
Discount 16 6143 170
Name 3 6143 30
Phone 9 6143 115
Postal-Code 17 6143 80
Sales-Rep 11 6143 125
State 7 6143 70
Terms 15 6143 150
If you compare this sample between the two databases that you expect to be identical but actually are not in terms of CRC, you can see where the problem occurred.
Additional sample code:
OUTPUT TO rpos.txt.
FIND _file WHERE _file._file-name = "Customer" NO-LOCK.
PUT UNFORMATTED LDBNAME("dictdb") + "." + _file-name + "(CRC" + string(_file._crc) + ")"skip.
FOR EACH _field OF _file BY _field-rpos:
DISPLAY _order _field-name FORMAT "x(18)" _field-rpos WITH STREAM-IO.
END.
output file (rpos.txt):
bob1.Customer(CRC30242)
Order Field-Name &nbs.p; field-rpos
----- ------------------ ----------
10 CustNum 2
30 Name 3
40 Address 4
50 Address2 5
60 City 6
70 State 7
15 Country 8
115 Phone 9
110 Contact 10
125 SalesRep 11
180 Comments 12
130 CreditLimit 13
140 Balance 14
150 Terms 15
170 Discount 16
80 PostalCode 17
190 Fax 18
200 EmailAddress 19
.
FIX:
Once the CRCs are out of sync, the only way to get back in sync is to dump and load all of them and load them all with the same .df file. This essentially is starting from scratch and the process includes all sites that received your propagated changes.
The information presented above should explain why dumping one database's entire .df and loading into another does not necessarily give you identical databases. The order in which the schema is created/modified is not the same between the original and the one being loaded with the .df that was dumped.