On 13-Feb-2014 14:32 -0800, Briggs, Trevor (TBriggs2) wrote:
I'm sure that changing something in a file will change its <ed:
record format level> identifier, but I'm not sure the reverse is
true. I.e. the file may not change but the identifier might. This was
true, I seem to recall (but many moons ago), that some actions, such
as a save/restore or recreating a file on a different OS release
could cause the identifier to change even though the file, for all
practical purposes, was identical.
The record format level identifier should never change once set...
except as corrective for past defects in its generation. Even so, such
a correction would be discouraged, as the effects are quite negative.
However...
There were some defects for database record format level identifiers,
for which some fixes were delivered, and SQL TABLE objects were allowed
to have a changed RcdFmt LvlId value because the SQL does not utilize
them; i.e. there is no such thing as LvlChk in the SQL run-time, because
its effect is casting to properly map data rather than using
fixed\aligned-buffers. Thus anyone who had changed to use SQL DDL to
replace DDS, before having changed applications to use DML to replace
RLA, likely would have applications that were adversely affected by
those potentially changing\corrected [by regenerating of] the level
identifiers.
Other past defects with the hashing algorithm were left unchanged,
i.e. the defect became the function, specifically to avoid any
ill-effects from a changing value. It was only the concept that the SQL
cares not, for which a decision allowing the changing record format
level identifiers [of the SQL *FILE objects] was deemed acceptable.
FWiW: For many releases every SQL VIEW had all blanks [not even a valid
value] as its record format level Id, and over several more releases
after first assigning a value, some more corrections had been made for
those SQL *FILE object, because the nuances of both the query record
format and when the final format was produced were impacting the ability
of the generation of the proper hash.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.