Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Intelligence (Analytics)
Placement of data in a cell.
alecsia
<p>Hello! I need a piece of advice.</p>
<p> </p>
<p>I have one DataSet, but I place its data into two different but adjacent cells. I need data from the second cell to end on the line where data in the first cell ends…</p>
<p> </p>
<p>The first cell has information about correspondents; I use</p>
<pre class="_prettyXprint">
‘, ‘ + ‘\n’
</pre>
<p>in Aggregation Concatenation to put them one above the other. The second cell holds information about different delivery types for the correspondents from the first cell. Since the words are short (but this is not always the case), the first correspondent, being longer, ends on the second line, while its delivery type is still on the first. It is not obvious on that screenshot, but delivery types also change places, and the first sometimes appear to be the type for the second correspondent.</p>
<p> </p>
<p>How can I “attach†them to one another to show them the order of appearance and place them correctly?</p>
Find more posts tagged with
Comments
micajblock
<p>Can you attach a design with sample data to show the problem?</p>
alecsia
<p>Good morning!</p>
<p> </p>
<p>I have created the sample report. It is exactly the same and represents the same issue.</p>
<p> </p>
<p>I am using Aggregation Concatenation in the table binding of the DataSet “LASTNAME†to put LASTNAME and REPORTSTO the way they are. (Plus, tables have the parameter from the OFFICECODE DataSet).</p>
<p> </p>
<p>In the report’s preview the number <strong>1 002</strong> is assigned to Murphy, but this is wrong as we can see in the DataSet’s preview itself, he has no number at all. This number belongs to Patterson.</p>
<p> </p>
<p>In this case I need Murphy to have a blank line instead of <strong>1 002 </strong>and everyone else to have their respective numbers. </p>
micajblock
<p>As I rule I try to avoid nested tables for this exact reason. Is there a reason you are using concatenation instead of just using details?</p>
alecsia
<p>Yes, in my case the report is built upon a document ID: if I am using one DataSet I get duplicated results in first several cells. One DOC_ID can have several correspondents plus several delivery types, I don't need to split them into different details, I need them to be in one "portion" of a table in which each cell contains all correspondents or delivery types or something else.</p>
<p> </p>
<p>It is easier to separate DataSets, creating one DataSet with distinct DOC_ID and the second one with all information regarding these DOC_IDs. In this case, if I am not using concatenation in nested tables I am just getting duplicated results based on the DOC_ID parameter I am passing to the second table. As a result I am getting one DOC_ID with multiple correspondents or types, as many as there are rows in the second DataSet itself... </p>
<p> </p>
<p>It seems even if there is a way to put the information a bit differently in a cell, I still need to "glue" the data from different cells together so they "follow" each other and, as it is in my sample report, the NAME doesn't have wrong REPORTSTO... </p>
micajblock
<p>Why not group on DOC ID? Can you provide sample of your data (export to CSV)?</p>
alecsia
<p>I tried to group and I always have two issues with this: 1 - I am getting two detail rows if there were two similar DOC_IDs, first detail row is filled completely, while second has blank first several cells (which were the same) and others are filled. And 2 – if I manage to get rid of this result, then I always have issues with row counting… It tends to count “invisible†rows and I am getting 1,2,4 numbering while already having one group (usually it is a document date) and needing the counting to be in its frames, not sequential and without skipping.</p>
<p> </p>
<p>I also can group in the query, this eliminates duplicates, although I am having more than 20 items after “GROUP BYâ€â€¦ The report itself is very large and this is not probably the best variant in terms of a clean query, but this can be an option anyway. But I didn’t try to finish it this way, I am not sure I won’t have the same issue then. Since queries are already written, it would be easier to find some solution with displaying the data...</p>
<p> </p>
<p>I have created a sample .csv, but I forgot what type it should be, so I saved it in UTF-8. The file shows the simplest result of a query without any grouping in it: first four cells are always the same when having similar DOC_ID – this is simply one document with different CORR and DELIVERY.</p>
micajblock
<p>and what do you want the output to look like?</p>
alecsia
<p>I have attached the sample of preferable result.</p>
Matthew L.
<p>Here is an example that produces the results you are looking for.</p>
<p>I had to change your CSV file as it was missing a column name for the DOCDATE values and I added the DOC_ID 542563 as in your screenshot to demonstrate the â„– row functionality.</p>
<p> </p>
<p>For the split cells, I added an empty table to the group cell and dragged the main table's CORR and DELIVERY data elements from the detail row into the empty table's detail row. As long as the empty table doesn't have a binding, then the BIRT engine will iterate the detail's from the main table's data binding from within the sub table.</p>
<p> </p>
<p>Let me know if you have any questions about this example.</p>
alecsia
<p>It works great if I am having very short CORR names, but when they are long - this works incorrectly… I changed my .csv; I made the first CORR very long (usually they are) and I deleted POST_1 of the SECOND_CORR to leave a blank space: and I have attached the result. POST_2 belongs to the THIRD_CORR, but it appears much higher than it should be…</p>
<p> </p>
<p>I have found a workaround, but I am not fully satisfied with it. I just merged two cells in my table and put there a new table with two columns. I placed CORR and DELIVERY in them. I have attached my result: I drew a line between two CORRs, and DELIVERies seem to be in right places. But in this case my CORRs are not separated by commas, usually I use Aggregation Concatenation for this. I can separate them in my query, but this makes my last CORR have comma too, which I don’t need… Plus, I need to align borders inside my main table to make this inner table look like two separate cells within a main one, this never works well!</p>