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 ?

Agile Talent Asked on February 14, 2017 in Agile PLM (v9),   Product Collaboration.
Add Comment
5 Answer(s)

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

Agile User Answered on February 15, 2017.
Add Comment

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?

Agile Talent Answered on February 15, 2017.
Add Comment

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

Agile User Answered on February 15, 2017.
Add Comment

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.

Agile Angel Answered on February 16, 2017.
Add Comment

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.

Agile Talent Answered on February 16, 2017.
Add Comment

Your Answer

By posting your answer, you agree to the privacy policy and terms of service.