Description: The current implementation of the grid control takes a large performance hit when the underlying result set includes multiple CLOB fields and the fields hold in excess of 64K worth of text. This is not backend specific, it is a problem whether an embedded data engine (hsql, firebird) or external (mysql, postgress) The problem does not happen for individual data controls on forms. The problem can be mediated in the Table View by hiding the CLOB fields at run time. Waiting on word back from a DB owner about using this data as an attachment - if I don't get that by this afternoon will gin up some test data separately and attach that. Steps to Reproduce: 1. Open any ODB attached to a datasource which includes a table including multiple clob fields (firebird) or memo fields (hsql) for instance. 2. Go to the Tables section 3. Open the table with the CLOB fields 4. Try to move through the table my scrolling. Actual Results: With a test file here of only 20 records, but all 20 records holding 100K text loads in three clob fields the performance comes to a grind. Expected Results: The table view should scroll without undue delays. Reproducible: Always User Profile Reset: No Additional Info: The current grid control, and all data controls, can only display the first 64K of text and I think the data being greater that that may trigger some error handling as the root of the problem here, but that is just a guess on my part.
What do you get when switching to direct SQL? Have tested this with the new BaseDocumenter. Opening a table ("OBJECTS") is very slow (16GB Memory, I5-Pozessor). But there is the same result when starting the query in Tools > SQL: SELECT * FROM "OBJECTS". Last a long time to show the result.
(In reply to robert from comment #1) > What do you get when switching to direct SQL? > Have tested this with the new BaseDocumenter. bingo, that is an excellent databases as an example. BTW; In that particular case it gets worse, for me here anyways, when the database is moved into firebird; once converted the 6.2 builds are worse performance than the 6.1 and prior releases. IN fact it got worse of late: with the lastest build: Opening the 'objects' table triggers multiple screen updates in the Table View window and have ended up killing Libreoffice because it never seems to finish *IF* I try to scroll the tablecontrol. (I didn't try the HSQL version of the file today) > .... Opening a table ("OBJECTS") is > very slow (16GB Memory, I5-Pozessor). But there is the same result when > starting the query in Tools > SQL: SELECT * FROM "OBJECTS". Last a long time > to show the result. The delay does not appear to be in the creation of the result set, which you can see if you base a form off the query definition. The new form wizard for instance does not include CLOB fields in a tablecontrol by default, you can of course use a add a sub-form in the wizard based on the same querydef and put the first of the CLOB fields on the form. In this configuration, even if you add two more text controls for the other two CLOB fields, the form will open up quick as can be and the tablecontrol is not delayed in any way as you scroll through it. The text controls change contents as you do. It appears the real problem is with how the table control is pulling data for the clob fields when configured to display them. The RFE here is to refactor the tablecontrol to address the performance when CLOB fields are included. (there could be a sister issue about BLOB fields, but seemed better to keep them separate)
edit - forget the line about what the form wizard does. It should just say if you leave the clob fields out of the gridcontol and then use a sub-form....
In a form the Memo-fields were not available for a tablecontrol. So the form only loads the content of one field, not of 47 rows or how much a table will load to the cache. If the result is the same with Tools > SQL: SELECT * FROM "OBJECTS" we can't only say it is a problem of tables and queries in the GUI. With Tools > SQL I have to wait a long time before the content of the query will be shown. It works - but very slow ...
You might want to consider whether this is a duplicate of bug 83999
(In reply to Alex Thurgood from comment #5) > You might want to consider whether this is a duplicate of bug 83999 Does it matter - the problem is real, it is getting worse.
(In reply to Drew Jensen from comment #6) > (In reply to Alex Thurgood from comment #5) > > You might want to consider whether this is a duplicate of bug 83999 > > Does it matter - the problem is real, it is getting worse. But I will comply with the rules and set the issue to duplicate moving it out of sight and mind. BTW the multi-line input setting seems to be a big player here. A tablecontrol in a Table View and Query View use 'Multi-Line Input' = True on by default, but when embedded in a Form that setting is off by default.
*** This bug has been marked as a duplicate of bug 83999 ***