To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=102625
User ludob changed the following:
What |Old value |New value
================================================================================
Status|RESOLVED |UNCONFIRMED
--------------------------------------------------------------------------------
Resolution|FIXED |
--------------------------------------------------------------------------------
------- Additional comments from lu...@openoffice.org Fri Dec 3 16:55:58 +0000
2010 -------
I had a look at the changeset for "dba34c: #i102625# only fetch rows when the
view moves outside the scope of the rowset window ". Apparently we are talking
about different things...
When opening a table in a table view, one or more SELECT * FROM table WHERE 1=0
is executed. Then a SELECT * FROM table. Then, to fill the form, a number of
SELECT * from xx where key = ?. You addressed a problem with the last part while
the problem reported is with the second part (the get the complete table). The
complete table needs to be traversed to get the key values but there is no
reason to get all the data from the table to use only the key values to re-get
everything again one row at the time.
I did some debugging: here is the stacktrace for the
OPreparedStatement::executeQuery that does the select * from xx:
odbcbasemi!connectivity::odbc::OPreparedStatement::executeQuery+0x94
[g:\ooo\dev300_m92\connectivity\source\drivers\odbcbase\opreparedstatement.cxx @
293]
dbami!dbaccess::OPreparedStatement::executeQuery+0xde
[g:\ooo\dev300_m92\dbaccess\source\core\api\preparedstatement.cxx @ 227]
dbami!dbaccess::ORowSet::impl_prepareAndExecute_throw+0x4ed
[g:\ooo\dev300_m92\dbaccess\source\core\api\rowset.cxx @ 1681]
dbami!dbaccess::ORowSet::execute_NoApprove_NoNewConn+0xe0
[g:\ooo\dev300_m92\dbaccess\source\core\api\rowset.cxx @ 1805]
dbami!dbaccess::ORowSet::execute+0x17f
[g:\ooo\dev300_m92\dbaccess\source\core\api\rowset.cxx @ 1588]
frmmi!frm::ODatabaseForm::executeRowSet+0x35b
[g:\ooo\dev300_m92\forms\source\component\databaseform.cxx @ 1261]
frmmi!frm::ODatabaseForm::load_impl+0x388
[g:\ooo\dev300_m92\forms\source\component\databaseform.cxx @ 2919]
frmmi!frm::ODatabaseForm::load+0x4f
[g:\ooo\dev300_m92\forms\source\component\databaseform.cxx @ 2702]
dbumi!dbaui::SbaXDataBrowserController::reloadForm+0xf7
[g:\ooo\dev300_m92\dbaccess\source\ui\browser\brwctrlr.cxx @ 733]
dbumi!dbaui::SbaTableQueryBrowser::implLoadAnything+0x5ec
[g:\ooo\dev300_m92\dbaccess\source\ui\browser\unodatbr.cxx @ 2333]
dbumi!dbaui::SbaTableQueryBrowser::implSelect+0x1bfb
[g:\ooo\dev300_m92\dbaccess\source\ui\browser\unodatbr.cxx @ 2612]
dbumi!dbaui::SbaTableQueryBrowser::implSelect+0x92
[g:\ooo\dev300_m92\dbaccess\source\ui\browser\unodatbr.cxx @ 2389]
dbumi!dbaui::SbaTableQueryBrowser::impl_initialize+0x1e95
[g:\ooo\dev300_m92\dbaccess\source\ui\browser\unodatbr.cxx @ 3160]
dbumi!dbaui::OGenericUnoController::initialize+0x51b
[g:\ooo\dev300_m92\dbaccess\source\ui\browser\genericcontroller.cxx @ 408]
dbumi!DBContentLoader::load+0x1949
[g:\ooo\dev300_m92\dbaccess\source\ui\browser\dbloader.cxx @ 320]
fwkmi!framework::LoadEnv::impl_loadContent+0x4b8
fwkmi!framework::LoadEnv::startLoading+0x87
fwkmi!framework::LoadEnv::loadComponentFromURL+0x81
fwkmi!framework::Frame::loadComponentFromURL+0x94
dbumi!dbaui::DatabaseObjectView::doDispatch+0x7a4
[g:\ooo\dev300_m92\dbaccess\source\ui\misc\databaseobjectview.cxx @ 164]
dbumi!dbaui::DatabaseObjectView::doCreateView+0x86
[g:\ooo\dev300_m92\dbaccess\source\ui\misc\databaseobjectview.cxx @ 119]
dbumi!dbaui::DatabaseObjectView::openExisting+0x4b
[g:\ooo\dev300_m92\dbaccess\source\ui\misc\databaseobjectview.cxx @ 106]
dbumi!dbaui::OApplicationController::openElementWithArguments+0xefa
[g:\ooo\dev300_m92\dbaccess\source\ui\app\appcontroller.cxx @ 1926]
dbumi!dbaui::OApplicationController::openElement+0x69
[g:\ooo\dev300_m92\dbaccess\source\ui\app\appcontroller.cxx @ 1827]
dbumi!dbaui::OApplicationController::onEntryDoubleClick+0xf7
[g:\ooo\dev300_m92\dbaccess\source\ui\app\appcontroller.cxx @ 1787]
dbumi!dbaui::OAppDetailPageHelper::OnEntryDoubleClick+0x76
[g:\ooo\dev300_m92\dbaccess\source\ui\app\appdetailpagehelper.cxx @ 1060]
dbumi!dbaui::OAppDetailPageHelper::LinkStubOnEntryDoubleClick+0xf
[g:\ooo\dev300_m92\dbaccess\source\ui\app\appdetailpagehelper.cxx @ 1057]
tlmi!Link::Call+0x11
dbumi!dbaui::DBTreeListBox::DoubleClickHdl+0x1c
[g:\ooo\dev300_m92\dbaccess\source\ui\control\dbtreelistbox.cxx @ 468]
svtmi!SvImpLBox::MouseButtonDown+0x18c
>From what I can see, in ORowSet::execute_NoApprove_NoNewConn in
dbaccess/source/core/api/RowSet.cxx, line 1809 impl_prepareAndExecute_throw()
causes the "SELECT * from xx" using statementhandle 1, line 1830
m_pCache->setFetchSize(m_nFetchSize) and 1831 m_pCache->createIterator(this);
does the "SELECT * from xx where key = ?" using statementhandle 2. The first
query is used to provide the key value for the second query. But since all data
are already retrieved why not just fetch them instead of re-querying the table
one row at a time? Or, as MSAccess does, query 1 does a "select keys from xx",
and query 2 a "SELECT * from xx where key = ?".
If you are interested I can attach an ODBC trace that shows clearly that data
are loaded twice. ODBC traces are lengthy though.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org
For additional commands, e-mail: issues-h...@dba.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org
For additional commands, e-mail: allbugs-h...@openoffice.org
