nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Duplicated computed columns

DMUK

Hi all,

I am coming up against a very annoying problem which I keep semi solving but further work on the report keeps coming back to bite me on the ****.

Essentially I have a big query, then a load computed columns. If I work on my report within the dataset or anywhere else (haven't narrowed it down) I get computed column duplication and then the report fails to run.

As an example, the query generates the following fields:

FIRST NAME
LAST NAME
AMOUNT
TAX

In computed columns I have these:

FULL NAME
FULL AMOUNT

I have a table bound to this dataset and use the results in the table.

Now my error manifests itself as the following:

"Column binding FULL NAME has referred to a data set column "FULL NAME" which does not exist."

Looking at output columns, all the original fields are there (all 6) plus the Computed Columns are there with numbers appended:

FIRST NAME
LAST NAME
AMOUNT
TAX
FULL NAME
FULL AMOUNT
FULL NAME7
FULL AMOUNT8

The numbers vary according to how many fields are already there.

So FULL NAME still exists in the dataset, but somehow BIRT has managed to duplicate it and is now looking for FULL NAME7 - FULL NAME won't cut the mustard.

I can get around it just before I publish the report by editing the tables dataset and removing all the rogue columns and saving straight away but as soon as I do anything else they appear back in the tables dataset (they are always in the dataset itself).

Any help appreciated - this is driving me insane!

Find more posts tagged with

Comments

mwilliams

Hi DMUK,

I can't say I've seen anything like this before. Is this something you can reproduce with the sample database? What version of BIRT are you using?

DMUK

<blockquote class='ipsBlockquote' data-author="mwilliams">Hi DMUK, 
 
I can't say I've seen anything like this before. Is this something you can reproduce with the sample database? What version of BIRT are you using?</blockquote>
 
No not with the sample database, only seems to be this particular report. 
 
BIRT 2.5.0.

mwilliams

DMUK,

If you rebuild that report again from scratch, do you experience the same thing? Maybe it's just a glitch in that report, somehow.

stf

I encountered this problem for many times, and i hope someone can solve this.

stf

HI,DMUK 
I'm facing with the same problem,do you get any solutions to this? 
<blockquote class='ipsBlockquote' data-author="DMUK">Hi all, 
 
I am coming up against a very annoying problem which I keep semi solving but further work on the report keeps coming back to bite me on the ****. 
 
Essentially I have a big query, then a load computed columns. If I work on my report within the dataset or anywhere else (haven't narrowed it down) I get computed column duplication and then the report fails to run. 
 
As an example, the query generates the following fields: 
 
FIRST NAME 
LAST NAME 
AMOUNT 
TAX 
 
In computed columns I have these: 
 
FULL NAME 
FULL AMOUNT 
 
I have a table bound to this dataset and use the results in the table. 
 
Now my error manifests itself as the following: 
 
"Column binding FULL NAME has referred to a data set column "FULL NAME" which does not exist." 
 
Looking at output columns, all the original fields are there (all 6) plus the Computed Columns are there with numbers appended: 
 
FIRST NAME 
LAST NAME 
AMOUNT 
TAX 
FULL NAME 
FULL AMOUNT 
FULL NAME7 
FULL AMOUNT8 
 
The numbers vary according to how many fields are already there. 
 
So FULL NAME still exists in the dataset, but somehow BIRT has managed to duplicate it and is now looking for FULL NAME7 - FULL NAME won't cut the mustard. 
 
I can get around it just before I publish the report by editing the tables dataset and removing all the rogue columns and saving straight away but as soon as I do anything else they appear back in the tables dataset (they are always in the dataset itself). 
 
Any help appreciated - this is driving me insane!

</blockquote>

mwilliams

Hi stf, 
 
Can you recreate this with the sample database? I'm not sure if it's recreateable with the sample database though, as DMUK was unable to reproduce it. You may also search the bug list at <a class='bbc_url' href='http://www.eclipse.org/birt/phoenix/reportabug.php'>BIRT: Reporting Bugs and Requesting Enhancements</a> to see if anything similar has been reported.

stf

I can't recreate it using the sample database either.
I think there's a difference between the sample db and user's db:I created a dataset using my own database, including a dataset parameter .When i click the "preview results" in the "edit data set", i got an error:can not set null value to parameter 1. But when using the sample db,there's no error.

stf

Hi,mwilliams 
The bug is reported in :<a class='bbc_url' href='https://bugs.eclipse.org/bugs/show_bug.cgi?id=284544#c1'>https://bugs.eclipse.org/bugs/show_bug.cgi?id=284544#c1</a> 
 
I think i have found a solution to this bug. 
First,let me introduce you the original xml source and then the changed xml source when computed columns is duplicated. 
1.original xml source 
<data-sets> 
<oda-data-set...> 
 
*********************************** 
<list-property name="computedColumns"> 
... 
<property name="name">stf</property> 
... 
</list-property > 
*********************************** 
<structure name="cachedMetaData"> 
<list-property name="resultSet"> 
...... 
<structure> 
<property name="position">11</property> 
<property name="name">stf</property> 
<property name="dataType">string</property> 
</structure> 
...... 
</list-property > 
</structure> 
*********************************** 
<list-property name="resultSet"> 
.... 
<structure> 
<property name="position">11</property> 
<property name="name">stf</property> 
<property name="dataType">string</property> 
</structure> 
..... 
</list-property > 
</oda-data-set> 
</data-sets> 
 
************** 
I assume the <list-property name="resultSet">tag under <oda-data-set> tag lists all the columns from the db. 
'stf' is the computed column,it is the computation of other columns,not from the database.But it is listed in the <list-property name="resultSet">tag. 
So the birt report engine think that the "stf" column listed in the <list-property name="resultSet">tag is from db. For the computed column "stf" has the same name, the engine changes it to "stf_12". 
The xml source is changed as follows: 
2.changed xml source: 
<data-sets> 
<oda-data-set...> 
*********************************** 
<list-property name="computedColumns"> 
... 
<property name="name">stf_12</property> 
... 
</list-property > 
*********************************** 
<structure name="cachedMetaData"> 
..... 
<list-property name="resultSet"> 
<structure> 
<property name="position">11</property> 
<property name="name">stf</property> 
<property name="dataType">string</property> 
</structure> 
<structure> 
<property name="position">12</property> 
<property name="name">stf_12</property> 
<property name="dataType">string</property> 
</structure> 
</list-property > 
..... 
</structure> 
*********************************** 
<list-property name="resultSet"> 
.... 
<structure> 
<property name="position">11</property> 
<property name="name">stf</property> 
<property name="dataType">string</property> 
</structure> 
..... 
</list-property > 
</oda-data-set> 
</data-sets> 
3.my solutions 
I don't know why the computed column is listed in the <list-property name="resultSet">tag under <oda-data-set> tag. I think this is the bug! 
 
What i do is 
1)delete the computed column from the <list-property name="resultSet">tag 
2)delete the newly created column from the 
<structure name="cachedMetaData"> 
<list-property name="resultSet"> 
<structure> 
tag. 
3)change the name of the computed column name. 
 
<data-sets> 
<oda-data-set...> 
*********************************** 
<list-property name="computedColumns"> 
... 
<property name="name">stf</property> 
... 
</list-property > 
*********************************** 
<structure name="cachedMetaData"> 
<list-property name="resultSet"> 
...... 
<structure> 
<property name="position">11</property> 
<property name="name">stf</property> 
<property name="dataType">string</property> 
</structure> 
...... 
</list-property > 
</structure> 
*********************************** 
<list-property name="resultSet"> 
.... 
(********delete the computed column****) 
..... 
</list-property > 
</oda-data-set> 
</data-sets>

MichaelG

Hi stf,

this is a nice workaround

My workaround is to rename the computed columns before I change the statement. After changing I set the names back. It is ok, if you make a small change. But if you have more to do it goes to a low performance programming...

In meanwhile, is there bugfix available?

Greetings, Michael

gert

<blockquote class='ipsBlockquote' data-author="'stf'" data-cid="57077" data-time="1258711934" data-date="20 November 2009 - 03:12 AM">
I encountered this problem for many times, and i hope someone can solve this. </blockquote>
 
Check your jdbc driver. I had the same problem with postgres jdbc 7.2 driver. 
That version does not support schema names. In Edit DatSet - query window, schema names are blank instead of 'public'. With the old driver changing a query that uses a parameter usually resulted in duplicated computed columns. 
I changed to a newer jdbc (postgresql-9.0-801.jdbc4.jar). That one shows information_schema, pg_catalog and public in the query designer. 
In Edit DataSet - Output Columns, Display Name for the normal columns are filled now. The designer probably gets upset if these are empty when you change a query. 
No problems with computed columns anymore (so far). 
 
Gert