Community
Participate
Working Groups
The number of rows fetched from database should be limitted when creating or modifying a datasource. Currently it seems like BIRT is retrieving all the rows from the table, and (in our scenario) it's a huge table. As the row fetching blocks user operations, it impacts usability quite badly (maybe the rows could be displayed from a background worker thread?). It should be an option on the BIRT preferences page. A similar option should be available for limiting the number of rows retrieved while previewing the report (with a button per datasource to "Show all", if there are more rows than those shown).
Moved to 1.0.1 as a requested improvement. Added keywords.
Data set preview already limits result set to first 500 rows. Can you please verify if this is working for you? The suggested enhancements make sense. The preview row limit should be user configurable. It will also be nice to add a "More rows" or "Show all" button in the preview pane.
Sorry, the data displayed is certainly not the full table contents. However, BIRT is very slow retrieving the preview data, and the usability issues remain. Using another tool (DBVisualizer) to query the table, limitting the result to 30.000 tuples, it takes about 20 seconds (during which, a counter is updated every 100 tuples, so the user knows that the app is working). Using BIRT preview, it takes more than 4 minutes for 500 tuples, with no perceived progress and freezing Eclipse. For the record, the table contains 36 columns, 30 of them are VARCHAR(50), 3 are TIMESTAMP and 3 are BIGINT. Most of the VARCHARs are NULL. The table has a total of 30.747.214 rows. I'm changing the title to something more relevant.
A couple more questions: (1) Did you run identical SQLs when you compare BIRT preview performance with DBVisualizer? Does DBVisualizer use JDBC, and if so is it using the same JDBC drivers as BIRT? (2) Can you attach the content of the SQL that runs slowly to this bug? (3) What's the Java VM heap size setting you use to start Eclipse? Does the performance problem persist if you double the heap size? (Use the "-vmargs -Xmx512m" argument on Eclipse command line to set heap size to 512MB for example).
Sorry for the late response... I've traced this to a parameter in the conection string. My DB is an SQLServer (with the MS provided JDBC driver) and I was using the parameter "connectionMethod=cursor" with DBVisualizer, but not with BIRT. This parameter changes between the way data is sent to the client. With "cursor" method, the preview runs much faster. The difference is that "cursor" opens a DB cursor which is used to read the data under demand. If it is not specified, de DB feeds the whole data to the client (so it doesn't care how many rows are actually read). (I'm not 100% sure of my own explanation, but the point is that, with similar conenction strings, BIRT preview and DBVisualizer run with equivalent response times). I'm marking the bug as INVALID. For the record, I'll answer the questions you asked: (In reply to comment #4) > (1) Did you run identical SQLs when you compare BIRT preview performance with > DBVisualizer? Yes. > Does DBVisualizer use JDBC, and if so is it using the same JDBC > drivers as BIRT? Yes. > (2) Can you attach the content of the SQL that runs slowly to this bug? I'll paste it, as it is really simple... select * from gnsql0.GNVATMHQ where VTME_IT_TSCarga > '23/06/2005' > (3) What's the Java VM heap size setting you use to start Eclipse? Does the > performance problem persist if you double the heap size? (Use the "-vmargs > -Xmx512m" argument on Eclipse command line to set heap size to 512MB for example). It was already set at that level.
Vierified in the Build 20051220
