Skip to Content
Author's profile photo Marc Kuipers

SAP FC – Archiving; what technically happens to the consolidation tables



You can use the Archiving Tool to store historical consolidated data in archive databases and still access it from the Financial Consolidation application.

This document shows what technically happens at DB level to the tables




The consolidations in FC are stored in ct_coXXXX tables. The XXXX indicates a unique identifier and the data for each consolidation definition will be stored in one single table.


You can determine what table holds the data by using this SQL


/* Consolidated */

select, as ‘category’,

ltrim(str(1900+(p.updper&536608768)/262144)) + ‘.’ +

right(’00’+ltrim(str((p.updper&253952)/8192)),2) as ‘period’,

  1. as ‘scope’,
  2. as ‘variant’,
  3. as ‘currency’

from ct_coref p, ct_phase a, ct_scope_code b, ct_variant c, ct_curncy d

where and

  1. p.scope = and
  2. and
  3. p.curncy =



For example, the consolidation data for {A – 2016.01 – SAP – SAP – USD} is stored in ct_co0050






When you archive (for full documentation, see section “12 Archiving tool” of the “SAP BusinessObjects Financial Consolidation Administrator’s Guide”

you first connect to the source database (and also specify the target database, in my example FC_BAK)




You then select the consolidation(s) you want to archive.

In my example, I take the consolidation {A – 2016.01 – SAP – SAP – USD}




When selecting “Execute” the system will show what table will be backed up. Here you can verify that the correct ct_coXXXX table is selected (in this example, it is ct_co0050)




The archiving completes (100%)




What has been done in DB’s


1. In the original DB (FC10) the table has been deleted




2. In the backup database (FC_BAK, in this example), the table has been created




3. In the original DB, there is now a ‘view’ ct_co0050 which is linked to the archived table (i.e. a view to a different DB schema)


The archive tool uses this during the ‘archive’ process


CREATE VIEW dbo.viewname


  SELECT column_names

    FROM [AnotherServer].[AnotherServerDatabase].dbo.[Table1];






The result is that on the original database, the archiving of the consolidation table is completely transparent

If you run an SQL (e.g. FC report, Cube Designer deployment), the result will still be the same, although the table is physically in a different DB



Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Vielen Dank

      Author's profile photo Yvonne Benz
      Yvonne Benz

      Very helpful! Thank you.

      Author's profile photo Pedro Fernandes
      Pedro Fernandes

      Hey Marc,

      Can you also post it on the JAM.



      Author's profile photo Marc Kuipers
      Marc Kuipers
      Blog Post Author

      Will do - thanks

      Jam L.

      Author's profile photo Rizwan Tahir
      Rizwan Tahir

      Thank you, Marc! This is indeed helpful clarification.

      - Rizwan

      Author's profile photo Former Member
      Former Member

      An excellent post and great explanation. Thank Marc,

      My question is, what are the benefits of archiving production database?

      Will there be a performance drop when users try to retrieve data?

      Author's profile photo Marc Kuipers
      Marc Kuipers
      Blog Post Author

      Hello Mojtaba

      The key benefit is that your DB will be smaller, so maintenance tasks like backup, will be a lot faster.

      Obviously, there will also be less disk space used (although you still need space for your archive DB)

      In my tests, there was no performance issue at all. Selecting data from a view that is connected to another physical DB will depend on the connection between the 2 DBs.