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; } } }

creating new table rows in script

gib65

Hello, I'm wondering if there's a way to add rows to a table dynamically in script. I've got a table in a report and I'm starting in the onCreate script for the table. Would this be the right place to do it? And what would a script that creates new rows in a table, and then adds data to it, look like?

Find more posts tagged with

Comments

BRM

What is your requirement? If it is to make the table do something different based on characteristics of your data I find it is much easier (and easier to maintain) to set up those report elements in the designer and conditionally hide their visibility at run time.

gib65

I'll try to explain myself in a bit more detail: I'm trying to populate a table with data from a 3D array that I created in script. So it's not a dataset. So I can't bind the table to it in the usual way. This means that I have to create the table dynamically. i.e. I have to iterate through the array and create rows for each step in the iteration. Ultimately, I want to do this for several different tables (each one being a different kind of table so I can't just repeat the same table). Each table will consist of data from a different index in the 2nd dimension of the array. That is to say, if you think of the array as [person's ID][tax form][field data], then each table represent a tax form (i.e. a T4 slip or a T3, etc.). So the script for, say, the T4 table will look into [person's ID]["T4"] and iterate through the field data at that index filling in the table with that data. The script for, say, the T3 table will look into [person's ID]["T3"] and so on. 
 
The original dataset from which I created this 3D array was just too disorganized and contained superfluous data, so I couldn't use it (at least, I couldn't figure out a simple way to bind it to the many tables I need). So I created a more organized and ordered array in script. Of course, how to bind the data in the array to the tables now becomes the tricky part, but I figured there must be a way to do it even if I have to create each row dynamically through script.

BRM

I get it. I am not a scripting expert and certainly not with something as complex as you describe. Is is possible to do the rearrangement/cleaning of the data in SQL? Then you would have datasets you could bind tables to. You might also have a look at these<a data-ipb='nomediaparse' href='http://www.birt-exchange.org/forum/index.php?/topic/20572-dynamic-table-creation-in-birt/'>http://www.birt-exchange.org/forum/index.php?/topic/20572-dynamic-table-creation-in-birt/</a> <a data-ipb='nomediaparse' href='http://www.birt-exchange.org/devshare/_/designing-birt-reports/1099-add-column-to-table-dynamically'>http://www.birt-exchange.org/devshare/_/designing-birt-reports/1099-add-column-to-table-dynamically</a> <a data-ipb='nomediaparse' href='http://digiassn.blogspot.com/2007/11/birt-dynamic-adding-tables-and-columns.html'>http://digiassn.blogspot.com/2007/11/birt-dynamic-adding-tables-and-columns.html</a> Sorry I can't be more help.

gib65

<blockquote class="ipsBlockquote" data-author="BRM" data-cid="120380" data-time="1379437877"><div>Sorry I can't be more help.</div></blockquote> That's OK. In the end, I ended up doing something similar to what you suggested. The original query was just too messy (and so were the results). So I replaced it with several queries (or several stored procedures) that got only the data that I need for whatever tax form I'm making a table for at that point in the report. Predictably, I name them after the forms (T3, T4, etc.). They return data for only one person's tax form information, and so the results are usually limited to only a few dozen rows, which makes it extremely convenient for just eyeballing the results.

BRM

Glad you got it to work. I tend to try to do as much as I can in SQL before I get to BIRT. I find that easier to debug and maintain.