Created attachment 64149 [details] ODBC log file When I open an ODBC connection, expand the list of tables in the schema, and double-click on a table name, Base calls SQLTables for each base table in the schema. I would guess that all but one of these calls is unnecessary at this point. Can an expert confirm the necessity or otherwise of these calls? I choose a connection to PostgreSQL for the ODBC log file and backtrace because the driver source is available. Note for comparison ... (*) A connection to DB2/i shows similar calls to SQLTables except that ... - DB2/i does one more call SQLTables, this final call naming the table that I actually double-clicked. - Referencing a server with more base tables in the schema and which is, moreover, on the other side of the Atlantic Ocean makes the delay conspicuous. (*) With a direct connection to PostgreSQL (using the SDBC driver), Base does not execute the source line appearing in frame 2 of the backtrace. Looking into the backtrace, I suspect that the iteration through tables is happening in frame 7 (dbaccess/source/ui/browser/unodatbr.cxx:2187). The code at line 2180 reads ... Sequence< ::rtl::OUString > aNames = _xNameAccess->getElementNames(); const ::rtl::OUString* pIter = aNames.getConstArray(); const ::rtl::OUString* pEnd = pIter + aNames.getLength(); for (; pIter != pEnd; ++pIter) { if( !m_pTreeView->getListBox().GetEntryPosByName(*pIter,_pParent)) { I have master commit id a3a0b81, pulled around 2012-10-10 17:45 UTC and built with options --enable-symbols --enable-dbgutil --enable-crashdump --disable-build-mozilla --without-system-postgresql --enable-debug --enable-werror The platform for build and execution is $ uname -a Linux cougar-natty 2.6.38-15-generic #60-Ubuntu SMP Tue May 22 11:30:47 UTC 2012 i686 athlon i386 GNU/Linux $ gcc --version gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2
Created attachment 64150 [details] backtrace from suspected "extra" call to SQLTables
@Robert Please: can you have a look at this bugreport. Can you reproduce what report means?
@Jochen : Terry knows what he's doing, he's already helped debug other ODBC problems, so am setting this as NEW and passing directly to Lionel. Alex
@Lionel : your call I guess. Alex
According to Terrence's analysis, this problem is not ODBC-specific, but common to all backends, because backend-generic code asks the driver for information on each table. Hopefully it caches the result (!) Terrence, if you double-click on *two* tables, do you see any *more* SQLTables calls than if you click on one table? If you do, then the behaviour is indeed very stupid. I agree it would be better to load table information lazily as needed, but that's an enhancement. Will happily review patches for this. Some more explanations: With a PostgreSQL-SDBC connection, you don't see any call to connectivity::odbc::ODatabaseMetaDataResultSet::openTables (frame 2 of your backtrace) because that's already backend-specific code. The equivalent call in PostgreSQL-SDBC is pq_sdbc_driver::DatabaseMetaData::getTables (which corresponds to frame 3 of your backtrace, namely connectivity::odbc::ODatabaseMetaData::getTables). The more interesting stuff in the backtrace would be the values of catalog, schemaPattern, tableNamePattern. "bt full" instead of "bt" would probably give schemaPattern and tableNamePattern, as for the value of catalog, it seems you don't have the gdb-python pretty-printers correctly setup.
@lionel I am, alas, separated from my development machine for forseeable future. So, I cannot look forward to doing anything useful. From a memory so old that I hesitate to mention it, I *think* I have seen LO go through the whole list of tables a second time, but not necessarily the next time I double-clilck a table. Still, I could be dreaming. Terry.
Responding to coment 5 ... > Hopefully it caches the result (!) > > Terrence, if you double-click on *two* tables, do you see any *more* SQLTables > calls than if you click on one table? If you do, then the behaviour is indeed > very stupid. The answer depends on the driver, but in no case have I seen the bunch of calls that this bug report is about. For postgresql, I have seen no additional calls. For SQLite3 there is an occasional single additional call, at random so far as I can see. For db2/i. there is one additional call the first time each table is opened. > The more interesting stuff in the backtrace would be the values of catalog, > schemaPattern, tableNamePattern. For ODBC connections to PostgreSQL and db2/i, the schema is my schema, public and TENGER1 respecively. For SQLite3, schemaPattern is the null string. A direct connection to PostgreSQL goes through other schemas as well: I saw calls for 94 files in schemas including information_schema and pg_toast_temp1. > it seems you don't have the > gdb-python pretty-printers correctly setup. Indeed. I should take another look at setting that up.
For what little it is worth, I have used gdb to set bExpandAncestors to false at dbaccess/source/ui/browser/unodatbr.cxx:1185. The good news is that this avoids the bunch of calls to SQLTables that this bug report complains about. The bad news is that the Data View when it comes up shows no data. Backtraces from the calls to SQLTables for the double-clicked table, the last such call when I leave bExpandAncestors and the only call when I plug bExpandAncestors, are so different from each other that I cannot find parallels between them.
The bunch of calls to SQLTables is gone. For two ODBC backends, PostgreSQL and DB2/i, I see two calls to SQLTables the first time I double-click on a table name. Subsequent times, even if I have opened other tables in the meantime, do not SQLTables again. Thank you, Lionel. I think this was fixed in commit de53823101479e88d23963aa66e2ad64ebfa29cd Author: Ocke Janssen [oj] <Ocke.Janssen@oracle.com> Date: Mon Mar 28 12:10:16 2011 +0200 fs34b: #i117552# check if query before call getByName in every case and I suspect in the changes to SbaTableQueryBrowser::populateTree in dbaccess/source/ui/browser/unodatbr.cxx, so am marking the bug RESOLVED FIXED.