I'd also suggest checking with a different sample file or a clean configuration if anyone else runs into the same issue. It's a quick way to tell whether the problem is data-specific or something in the environment, and it can save a lot of time troubleshooting.

It definitely seems like something was updated behind the scenes. Pages have been loading a lot smoother on my end recently, so if a server migration happened, it was definitely a welcome change!

I always like giving new sounds a few listens before forming an opinion, especially on different headphones or speakers. It's interesting how much your impression can change after a bit more time with it.

Good suggestions above. I'd also verify that the data types and any joins or filters are doing exactly what you expect, since small mismatches there can lead to some confusing results. If you can share a simplified version of the report or query, it's usually much easier for people to spot the issue.

These AI inspired instructions worked for me which included creating a new data item which I had not tried in my earlier attempts to use the Minimum expression.

1. Open your report in Edit mode and go to Queries.
2. Create a New Data Item in your query and name it something like Unique_Record.
3. Set your expression using the following syntax:minimum([Column_to_Check] for [Grouping_Key_1], [Grouping_Key_2])(Replace Column_to_Check with the item you want to extract, and Grouping_Key with the core columns that define the unique entity).

Understood - as that is of course the appropriate (possibly only) long-term solution bus_pass_man.

I think the problem should be defined as someone messed up and corrupted the table (and possibly others too) and the incorrect data needs to be removed rather than how do I work around the corruption.  As such, there needs to be at least one meeting, probably more, involving a manager, almost certainly many sunrays up the chain, so that people in authority know about the problem.   

Good Day Cognos Experts,

I have a table which (thank goodness) has a unique key but appears that logical duplicates are being created in that table in error by the source program.  The downstream result is in the Report output I'm getting duplicate rows in my report because of later Joins I must do using either Study ID or Exam Number.

The three most relevant fields in this table are:
1. Study ID (by design almost unique)
2. Exam Number (no design intent to be unique)
3. Event Log ID (actual internally sequentially assigned key to the table and thus always unique). 

Offending records in this table look like this:
Study ID   Exam Number       Event Log ID
3261991    00000XR260044096  608448
3261991    00000XR260044096  608449

As shown above I've got two records where 100% of the data is identical except for the Event Log ID value.  I only want my Query to output a single occurrence of what appears to be duplicate records.  If I had a choice,  I think I'd prefer to use the "first" record.   

What can I do within the confines of my Query to focus the attention on just one of these two duplicates? 

I've tried adding "Minimum" to the left of the field Expression Definition like Minimum([Event Log ID]) but that didn't make any difference.  Maybe I've used that expression wrongly.

Thanks for sharing hints with me.

Quote from: timness on 07 Jun 2022 07:58:43 PMIE Tab in Chrome works on Windows 10, but not Windows 11 (unless someone knows how to get the Report Studio popup to work).

I've recently got IE tab in Chrome to work for Cognos Report Studio 10.2.2, in Windows 11.

In IE Tab settings, I use "IE 11 Standards Mode", in the "Popups & Tabs" section, I checked all the boxes.

By the way, the IE Tab version: 19.3.5.1

rent a car banjaluka https://drivelity-balkans.com/car-rental-banja-luka