SQL could provide a way to handle different formats, with its column renaming capability (field as newname) and its "case-end case" control structure. A UDF could be written to retrieve whatever controlling value you need, then use something like

case prodversion()
   when "Version1"
      then field1
   when "Version2"
      then field2
   else originalfield
end case
as originalfield

This way your original program uses the same field names. This can even handle data type changes with the various conversion (cast) functions.

HTH
Vern

At 08:21 AM 3/9/2004 -0800, you wrote:
Interesting.  I'm as surprised as you are that there is no record format
ID in the journal receiver.  Doesn't look like any easy way to
automagically handle different formats.

But then, your extraction app would have to be recompiled after every
format change anyway, so I think you've got the right idea with using a
cutoff timestamp.

BTW, did you notice that one of the *TYPE5 fields is "Arm Number"?  It's a
5-byte zone-decimal field.  What in the world is this about?  InfoCenter
describes this as "The number of the disk arm that contains the journal
entry."  I am baffled as to the usefulness of this information.

GA



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 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.