Skip to Main Content
IBM Data Platform Ideas Portal for Customers


This portal is to open public enhancement requests against products and services offered by the IBM Data Platform organization. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:


Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,


Post your ideas

Post ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,

  1. Post an idea

  2. Upvote ideas that matter most to you

  3. Get feedback from the IBM team to refine your idea


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

IBM Employees should enter Ideas at https://ideas.ibm.com



Status Not under consideration
Created by Guest
Created on Oct 7, 2025

Procedure to do a mass delete in the SQL-tables (outside the Controller interface).

It is very much work to execute the UNSUPPORTED solution described hereby. We require this because we perform regularly a datarefresh to another pillar. In the target pillar, other users need access to Controller, and it should taken many hours to delete the users (around 800!!) one by one in the interface.

Second reason: if some users remain the same (with the same access), the CAMid's of them can't even be reused because the are different from the one in the source pillar. So, a user that logs on gets another CAMid so that the SAME user appears twice in the database. It is difficult for administration tasks to figure out the correct userid to provide the necessary authorisation group.

We think that a lot of companies suffer with the same issue. At IBM, Nathalie.St.denis-peers helped us to complete this *unsupported* procedure which we had already created ourselves partly. 

Current unsupported procedure:
1) Create backup of Cognos controller DB in production
2) Create export of XCAMUSER/XUSER/XKONFIG/XMEDLEM/XNYST table in Cognos controller DB in acceptance
3) Export User rights in acceptance via export structures
4) Restore production db in acceptance
5) Truncate XCAMUSER table
6) Refill XCAMUSER table with previous taken export
7) Import user rights in acceptance via import structures (single mode)
8) Delete statements:
DELETE * FROM cognos.xkonfig WHERE NOT EXISTS ( SELECT 1 FROM cognos.xcamuser c
                                                                                               WHERE c.CONTROLLERUSER = cognos.xkonfig.anvid
                                                                                              )
                                                                       AND cognos.xkonfig.typ1 = 'U'
DELETE * FROM cognos.xnyst WHERE NOT EXISTS ( SELECT 1 FROM cognos.xcamuser c
                                                                                              WHERE c.CONTROLLERUSER = cognos.xnyst.frmedlem
                                                                                           )
                                                                    AND cognos.xnyst.frgrptyp like 'U%%'
DELETE * FROM cognos.xuser x WHERE NOT EXISTS ( SELECT 1 FROM cognos.xcamuser c
                                                                                               WHERE c.CONTROLLERUSER = x.userid
                                                                                             )
DELETE * FROM cognos.xmedlem WHERE NOT EXISTS ( SELECT 1 FROM cognos.xcamuser c
                                                                                                    WHERE c.CONTROLLERUSER = cognos.xmedlem.medlem
                                                                                                 )
                                                                           AND cognos.xmedlem.grptyp = 'U' or cognos.xmedlem.grptyp = 'Ux'7

9) Launch IP (to publish Controller via FAP to TM1)

Needed By Quarter
  • Admin
    Maximilien de Chestret
    Oct 22, 2025

    Hi Marc, I'm sorry to say, but your request appears to be quite specific to your internal process. We haven’t received similar requests from other customers, which makes it difficult for us to prioritize it over other ongoing requests. For now, we recommend following the manual procedure provided by our support team.

  • Guest
    Oct 15, 2025

    Hi Maximilien,

    We have no experience with de-activation of users, but I don't know if you understand what I mean with "different CAMid's": when changing the pillar where Controller is restarted after a DB-refresh (eg. Prod>Acpt), the CAMid for that same user that is RE-created (again) is DIFFERENT from the one in the other pillar. So, it's very confusing to find out afterwards in user management WHICH user is valid on this pillar. So, I would like you to reconsider this to make the user management more user-friendly.

    About de-activation of users: how do you deactivate quickly 800 users?

  • Admin
    Maximilien de Chestret
    Oct 14, 2025

    It's a complex request ( copies of PROD db to an ACCEPT db and change the users access) that we haven't heard from other customers. We don't plan to implement it. The workaround is to de-activate the users that should have no access to ACCEPT