This can be done at the DB level, something like:

select distinct(transferred) from change;
This will return the value for yes/no transfer
create table changeFullBk as select * from change;
update change set transferred=  xx  where class=6000;
this will update all Change orders. The script can be enhanced to exclude deleted changes and/or subclasses

Hope this helps
Florina

Thanks Florina.  Is the CHANGE table you mention on the Agile server, in the AGILE schema?

In the CHANGE table from Agile, I see 5 distinct TRANSFERRED values.  Here they are with counts:

SELECT count(*) from CHANGE where TRANSFERRED IS NULL    —  count = 102,796
SELECT count(*) from CHANGE where TRANSFERRED = ‘1’        —   count = 37
SELECT count(*) from CHANGE where TRANSFERRED = ‘1 100000000000000000000000000000’    —  count = 5
SELECT count(*) from CHANGE where TRANSFERRED = ‘10000000000000000000000000000000’   —  count = 3,263
SELECT count(*) from CHANGE where TRANSFERRED = ‘10100000000000000000000000000000’   —  count = 501

I tried using the ‘Set Transfer Flag’ from the ChangeCAST GUI.  The CHANGE.TRANSFERRED value was null, then I changed it to Yes from the GUI and it was still null.  Is there another CHANGE table local to ChangeCAST?

Change table is part of the agile schema, you need to connect as agile/tartan (default)
I don’t have a 932 system to get exact details but you can start with  using a Change #  with transfer flag set as you want  to set to all ECOs

select id, transferred from change where change_number=’XXXX’;

Also, look into the changes with different transfer flag to understand why the difference in flags

select change_number from change where TRANSFERRED = ‘1 100000000000000000000000000000’  ;
SELECT change_number  from CHANGE where TRANSFERRED = ‘10000000000000000000000000000000’  and rownum < 5 order by rownum;
SELECT change_number  from CHANGE where TRANSFERRED = ‘10100000000000000000000000000000’   and rownum < 5 order by rownum;
You can change the rownum to a lower number, but in general, review the changes returned to understand, from GUI perspective, why difference in transferred flags and determine which one is best for your update.

Once you decide on the transferred flag, backup change table, update and commit.
Of course, test it all in non production. For example, once update and commit, do you see CC attempting to reset the flag in GUI? I remember there is a CC wizard and you need to select from this point on…. ( sorry , ChangeCast is rather old and I haven’t worked with it in a while !)

Florina

Florina is correct in everything she has talked about. But something else to consider, is that it appears that you have 3 distinct destinations defined in ChangeCAST. Note that in TRANSFERRED, each bit is a yes/no (1=Yes, 0=No) as to whether the given change has been processed for the destination environment denoted by that bit. Given that you have a “1” in positions 1, 2 and 3 of the attribute values, it must be processing for 3 different destinations. You should be able to figure out which bit denotes which destination from the ChangeCAST setup. A null value in TRANSFERRED simply means that the change has not been processed by ChangeCAST at all. Weirdly, sometimes it only sets a single bit (where TRANSFERRED = “1”) instead of  setting the full value.
 Thus, if you want a change to not be processed for a given destination, set the correct bit in TRANSFERRED to be “1” in that position :
— this will prevent the change from being processed for destination 1
update change set transferred = ‘1’ || substr(transferred, 2) where change_number = ‘XXXX’;
— this will prevent the change from being processed for destination 3
update change set transferred = substr(transferred, 1, 2) || ‘1’ || substr(transferred, 4) where change_number = ‘XXXX’; 

 To really make the above work, you do need to set TRANSFERRED = ‘00000000000000000000000000000000’ where it is null.

An Oracle consultant told me the CHANGE table may have been used for that flag for older versions of ChangeCAST.  He told me to look at the TRANSFERFLAG table instead. 
Yes, that is the table I should be looking at.   The field in the table is TRANSFER_FLAG.   In ChangeCAST I set the flag to No, and this was what I saw in the table:

SELECT TRANSFER_FLAG FROM TRANSFERFLAG WHERE CHANGE_NUMBER = ‘BCO-0034’
Output
10000000000000000000000000000000

Then I went back into ChangeCAST and set the flag to Yes. I ran the query again and it shows this:

Output
11000000000000000000000000000000

In the future, I can update that field with the 1100… value to set them to Yes.