Kbase 18430: 4GL. Signatures, RAW-TRANSFER, Temp Tables and How they Interact
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
5/18/2010 |
|
Status: Verified
GOAL:
RAW-TRANSFER, file signatures and the use of temp tables
GOAL:
How a file's CRC and signature differ.
FACT(s) (Environment):
Progress 8.x
Progress 9.x
All Supported Operating Systems
OpenEdge Category: Database
OpenEdge Category: Language (4GL/ABL)
FIX:
There is a difference between a file's CRC and its signature. The importance of this distinction is evident when you deal with RAW-TRANSFER, a 4GL option commonly used in data replication.
The CRC of a table is a single 16 bit value that is computed based on the features of the table. The signature of a table is a description of the actual layout of the fields in the table.
As an example, suppose the field at position 2 is character, the field at position 3 is integer, the field at position 4 has extent 7 and is date, etc. Here, you cannot use the CRC of a table to derive the field layout, however you can do so by using the table's signature. The CRC is a 16-bit representation of the signature, which is less expressive by necessity.
The distinction between CRC and signature is important because with RAW-TRANSFER, the source and target tables must have the same signature.
A Progress bug found in Version 8.2B can possibly lead to the following error message:
Table signatures do not match in RAW-TRANSFER operation. (4955)
The reason for this was that the LIKE attribute is not creating a temp table that has the same signature as the database table.
In order to understand how this error can occur, some background as
to what happens when a schema change is performed on a table is necessary:
Suppose you remove a field from an existing table. Doubtless, the table's CRC changes. But more importantly, when RAW-TRANSFER is involved the table's signature also changes. However the table retains knowledge of the pre-existing field. To illustrate with a diagram:
Suppose you have a table with four fields, |1|2|3|4|. When you delete a field, a hole is left behind in the Schema information:
|1|2| |3|
If you create a temp-table LIKE this database table, the holes are removed, therefore the signature of the database and the temp tables do not match.
Progress Bug 19980304-001 outlines several workarounds that can be used to make the signatures match. At this point, these are the only solutions to the problem, and unfortunately both affect the table's CRC.
When the signatures do not match, the RAW-TRANSFER cannot take place. Furthermore, in order to get any old data written with the RAW-TRANSFER statement, you need a target table that has the old signature as well.
The two workarounds are as follows, with some anticipated Q&A to follow:
- Dump the table and its contents, delete the table, and then reload the table and its contents.
This of course results in a CRC change. This might also cause problems reading old data previously stored with RAW-TRANSFER.
- A more involved workaround whose results depend on the version of Progress you use is to add dummy fields to the table.
With this workaround you achieve the goal of filling in the holes. You can display _Field._ Field-Rpos to verify which record positions are used. (Bear in mind that position 1 is reserved and does not show up in your _Field records.)
NOTE: If you use Version 8.2 or later, Progress tries to add your fields to the end of your record (not reusing the gap fields). This is part of the "fast field add" feature of Version 8.x that allows you to add a field without updating all the records of the table in the database to actually physically reflect the new field.
To disable that feature (so you fill the holes), add fields with an
initial value of something other than the value "Unknown". The "fast field add" feature only goes into effect when the field you add has the "Unknown" value as its initial value.
NOTE: In Version 9.x, Progress does not re-use physical record positions at all. All fields are added to the end. However, in Version 9.x, the _Field._Field-Rpos is able to be set (so you need only to make sure that there are no gaps in your _Field-Rpos values for your table).
For example, you do not need to add new. fields to your table to fill in the gaps. Once you have no gaps in your _Field-Rpos values for your table, your temp-table defined LIKE your database table looks just like the database table, and you can use the RAW-TRANSFER statement between the tables without complaint.
Q and A:
- Some Progress customers might suggest that perhaps there is a way to store the schema and then somehow import it into the temp table structure to avoid the signature problem.
This is not a possible solution, according to Progress Development.
- What schema definition attributes can cause the signature to change?
_Field.Rpos, _data-type, and _Extent.
- If the signature stores the information about the record layout, can the signatures be read back and displayed to identify the field layout of the record stored?
In theory, yes, but it would not be easy, because the algorithm is complex. Also, the information is stored in a proprietary way for portability reasons, so it is not made public..