How to set Agile ChangeCAST transfer flag
We are using Agile ChangeCAST with our 932 Agile PLM. ChangeCAST sits on a different server. When we refresh our test Agile instance from Production, ChangeCAST thinks it needs to transfer EVERY Change Order since the beginning of time. Somehow the Transfer Flag gets set back to No. I want to set the Transfer Flag to “Yes” for every Change Order. Using the GUI, this can be done, but not for EVERY record. You need to specify a criteria and even then it only returns a max of 1000 records. I can Select All, and tell it to set the Transfer Flag to Yes. But this painful. Only 1000 at a time? I don’t know all the Change Order numbers. Is there a utility I can run to set the Transfer Flag to Yes for all ?
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
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 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’
Then I went back into ChangeCAST and set the flag to Yes. I ran the query again and it shows this:
In the future, I can update that field with the 1100… value to set them to Yes.