The program in question was going to to moving data from one table
with a 10a field, 'ABC1234567', to another table in which the field
could have been either 7p0 (old), as 1234567, or 10a (new), as
'ABC1234567'.
insert into <...>
select <...>
I didn't think v5r4's implicit casting was up to the task...but if it is....
Meanwhile, I think we got another solution that doesn't require the
program know what which destination format is in play..
Basically, we've got a central corporate server and many distributed
field boxes. We've got to expend one of our file fields from 7p0 to
10a. Not only is the file in question used on both central and field
boxes, but the field is part of data that is transferred from central
to the field boxes and loaded via a CPYF.
The plan is to expand the central system first, then over a period of
weeks, roll the changes to the field boxes. Between the time the
central box converts and all the field boxes are converted, the data
in 10a file from the central box would need end up in either the new
10a field or the old 7p0 field on a field box.
Thus the original question...
In talking to the developer, it seems to me that we can simply have
copies of the transmission file, the old 7p0 one and a new 10a one.
The program containing the CPYF will be included in the changes rolled
to the field boxes to copy from the file.
Charles
On Fri, Mar 4, 2011 at 2:45 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:
Any pros/cons to the above?
Does anybody have any additional ideas?
Perhaps... Is there really any requirement to know the difference?
There is implicit casting between the two types, and explicit casing is
legitimate to get a consistent type into the non-SQL program variables.
midrange.com
