Purpose (problem description)

This page handle the issue when you are getting a non zero value for Automated Function Points Deleted:


but there is No item to display in the list of Automated Function Points Deleted:

Observed in CAST AIP
Release
Yes/No
8.3.x(tick)
Observed on RDBMS
RDBMS
Yes/No
CSS(tick)

Step by Step scenario

  1. Run analysis and take a snapshot.
  2. Open CED.
  3. Navigate to the frame "FRAME PORTAL EFP VIEW"
  4. Click on "Automated Function Points Deleted".

Action Plan

  1. Check if the procedure dedouble_transaction and dedouble_datafunction was executed manually, if it's the case then there is no workaround for this issue, you have to restore the triplet corresponding to the previous snapshot and recompute the last snapshot without manually launching dedouble_transaction and dedouble_datafunction. Else if the procedure dedouble_transaction and dedouble_datafunction was not executed manually then please contact CAST Technical Support with the following Relevant input

Relevant input

  1. Screenshot from CED with URL visible
  2. Sherlock export with the following options: Export Logs (feature checked by default), Export Configuration files (feature checked by default), Export Computer Environment (feature checked by default), Export CAST Bases

Check if the procedure dedouble_transaction and dedouble_datafunction was executed manually

The dedouble_transaction and dedouble_datafunction are procudures located in the following localtion : <CAST_install directory>\InstallScripts\<storage service>\EFP_CENTRAL, where <storage service> is CastStorageService or Oracle or SqlServer.

In order to check if those procedures was executed manually or not, please perform the following steps:

  1. Run the following query to get the execution history of procedures DEDOUBLE_DATAFUNCTIONS and DEDOUBLE_TRANSACTIONS:

    SELECT * 
    FROM   dss_history dh 
    WHERE  dh.description LIKE 'DEDOUBLE_%Step 1 check % inconsistency%' 
            OR dh.description LIKE 'DEDOUBLE_%rows deleted%' 
    ORDER  BY dh.action_date, 
              dh.history_id; 
    

    Result example:


    "DEDOUBLE_DATAFUNCTIONS : Step 1 check datafunction inconsistency ";"2017-02-07 02:14:12.066829";99893
    "DEDOUBLE_TRANSACTIONS : Step 1 check transactions inconsistency ";"2017-02-07 02:14:13.389881";99896
    "DEDOUBLE_DATAFUNCTIONS : Step 1 check datafunction inconsistency ";"2017-03-22 03:39:48.596031";123053
    "DEDOUBLE_DATAFUNCTIONS : Step 1 check datafunction inconsistency ";"2017-03-22 03:40:01.045964";123057
    "DEDOUBLE_DATAFUNCTIONS : DSS_OBJECT_INFO number of rows deleted : 0";"2017-03-22 03:40:03.261505";123073
    "DEDOUBLE_DATAFUNCTIONS : DSS_LINKS number of rows deleted : 4";"2017-03-22 03:40:03.261936";123075
    "DEDOUBLE_DATAFUNCTIONS : DSS_LINKS number of rows deleted : 4";"2017-03-22 03:40:03.263759";123077
    "DEDOUBLE_DATAFUNCTIONS : DSS_TRANSLATION_TABLE number of rows deleted : 4";"2017-03-22 03:40:03.311807";123079
    "DEDOUBLE_DATAFUNCTIONS : DSS_OBJECTS number of rows deleted : 4";"2017-03-22 03:40:03.330753";123081
    "DEDOUBLE_DATAFUNCTIONS : Step 1 check datafunction inconsistency ";"2017-03-22 03:41:11.838902";123119


  2. Run the following query to get the migration:

    SELECT installer, 
           Max(revision_date) 
    FROM   sys_package_history 
    GROUP  BY installer 
    ORDER  BY Max(revision_date); 


    Result example:

    "CAST 7.0.1 ( Build 3464 )7.0.1.3464.01";"2011-02-22 11:30:11"
    "CAST 7.0.2 ( Build 3542 )";"2011-02-22 11:46:30"
    "CAST 7.0.2 ( Build 3542 )7.0.2.3542.01";"2011-03-15 15:08:54"
    "CAST 7.0.5  ( Build 3708 )";"2011-09-12 10:26:39.044"
    "CAST 7.0.5  ( Build 3708 )7.0.5.3708.087.0.5.3708.097.0.5.3708.107.0.5.3708.11";"2012-07-31 10:52:57.981096"
    "CAST 7.0.9 ( Build 4101 )";"2013-02-04 03:44:52.292087"
    "CAST 7.0.9 ( Build 4101 )7.0.9.4101.067.0.9.4101.15";"2013-11-06 03:43:25.427427"
    "CAST 7.0.9 ( Build 4101 )7.0.9.4101.067.0.9.4101.157.0.9.4101.167.0.9.4101.17";"2014-02-15 00:33:41.322409"
    "CAST 7.0.9 ( Build 4101 )7.0.9.4101.067.0.9.4101.157.0.9.4101.167.0.9.4101.177.0.9.4101.20";"2014-06-21 18:39:49.101022"
    "CAST 7.3.5 ( Build 7496 )7.3.5.7496.02";"2016-01-18 01:40:45.643127"
    "CAST 7.3.5 ( Build 7496 )7.3.5.7496.027.3.5.7496.03";"2016-02-18 07:58:59.949344"
    "7.3.5.7496.027.3.5.7496.03CAST 7.3.5 ( Build 7496 )7.3.5.7496.03.017.3.5.7496.057.3.5.7496.51";"2016-12-03 05:12:12.265285"
    "7.3.5.7496.027.3.5.7496.03CAST 7.3.5 ( Build 7496 )7.3.5.7496.03.017.3.5.7496.057.3.5.7496.517.3.5.7";"2017-02-07 02:24:34.988862"
  3. Compare and interpret the results:

    The procedures  DEDOUBLE_DATAFUNCTIONS and DEDOUBLE_TRANSACTIONS are called when there is a migration, so if those procedures was not executed manually the execution date from the 1st query should coincide with the last row of the second query. If we take our example, we can see that the procedures DEDOUBLE_DATAFUNCTIONS and DEDOUBLE_TRANSACTIONS were computed 2 times:

    1. One time on 2017-02-07 which coincide with the migration date retrieved from the second query

    2. A second time on 2017-03-22 which do not coincides with any migration date

    From this we can conclude that the procedures DEDOUBLE_DATAFUNCTIONS and DEDOUBLE_TRANSACTIONS was executed manually on 2017-03-22

Notes/comments

Ticket # 8379

Related Pages