A bit differently this time around:
+ remove Credits menu item from menu
+ remove License button from the About dialog
Change-Id: I07c1e115aa209ef1d69458f5b188d73caaae4294
These changes allow the user to optionally display the output
from SQL SELECT statements in the "Execute SQL Statement"
dialog.
Change-Id: I9209a9e3b5ed100a88fa467078deb9f38c571d42
Some of the code need the warnings suppressed - unavoidable when
dealing with the reflection interface.
Change-Id: I2016c3f904bcebc4e34556eb5d231fc25761a9ce
All of those defines (should) not be used at any point in the code.
False positives may exist, because some macro names are getting
generated by some template/macro foo. This is the version which
compiled fine for me.
Also there are many commented out lines removed.
Change-Id: I6394024682e4ab3691eb72707a9363d41ba31df8
The only part where one definition was used was commented out.
All other definitions in the hrc file were unused.
Change-Id: I257e61b96271685e9321211846a0021059924abe
The About dialog now houses these functions.
Change-Id: I7f751027564897a063d2910644c69680d471b6d9
Signed-off-by: Fridrich Štrba <fridrich.strba@bluewin.ch>
These RID definitions aren't used at any other point. So remove
them. Unused START and END definitions were commented out for
documentation purpose.
All definitions in basctl/source/basicide/tbxctl.hrc were unused,
so I removed this file.
Change-Id: I4713188a12b9da912b2a91b85ea4e54ca1aeb994
Update code to use factory method URLTransformer::create
Change-Id: I3fd2e838497bcfd8fc949615c0e7d60a6ea47118
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>, added some tweaks.
Update calls to factories to use new SimpleFileAccess::create method
Change-Id: Ie5b0696fe2228a9033b19969245a53c21a61aa14
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>, added some tweaks.
... BOOST_STATIC_ASSERT_MSG was added in boost 1.46, while the internal
boost is still at version 1.44, so use BOOST_STATIC_ASSERT instead.
Change-Id: I14f8e48e31956b34a1a907cd2c4e454a5715889b
We do a "SELECT * FROM table" just to fetch the primary key columns;
so reuse the same XResultSet to fetch all columns.
Else, we immediately issue a "SELECT * FROM table WHERE
primary_key=current_value" to read the other columns, which is
wasteful and particularly silly.
Commit 1ae17f5b03 already tried
to do that, but was essentially reverted piecewise because
it caused fdo#47520, fdo#48345, fdo#50372.
Commit c08067d6da94743d53217cbc26cffae00a22dc3a thought it did that,
but actually reverted commit 1ae17f5b03.
This implementation fetches the whole current row and caches it in memory;
only one row is cached: when the current row changes, the cache contains
the new current row.
This could be problematic (wrt to memory consumption) if the current
row is big (e.g. with BLOBs) and nobody is interested in the data
anyway (as would often be the case with BLOBs). Note that because of
our "SELECT *", the driver most probably has it in memory already
anyway, so we don't make the situation that much worse.
This could be incrementally improved with a heuristic of not
preemptively caching binary data (and also not LONGVARCHAR / TEXT /
MEMO / ...); a getFOO on these columns would issue a specific "SELECT
column FROM table WHERE primary_key=current_value" each time.
The *real* complete fix to all these issues would be to not do "SELECT
*" at all. Use "SELECT pkey_col1, pkey_col2, ..." when we are only
interested in the key columns. As to data, somehow figure out which
columns were ar interested in and "SELECT" only these (and maybe only
those with "small datatype"?). Interesting columns could be determined
by our caller (creator) as an argument to our constructor, or some
heuristic (no binary data, no "big" unbound data).
Also be extra smart and use *(m_aKeyIter) when getFOO is called
on a column included in it (and don't include it in any subsequent
SELECT).
However, there are several pitfalls.
One is buggy drivers that give use column names of columns that we
cannot fetch :-| Using "SELECT *" works around that because the driver
there *obviously* gives us only fetchable columns in the result.
Another one is the very restrictive nature of some database access
technologies. Take for example ODBC:
- Data can be fetched only *once* (with the SQLGetData interface;
bound columns offer a way around that, but that's viable only for
constant-length data, not variable-length data).
This could be addressed by an intelligent & lazy cache.
- Data must be fetched in increasing order of column number
(again, this is about SQLGetData).
This is a harder issue. The current solution has the nice advantage
of completely isolating the rest of LibO from these restrictions.
I don't currently see how to cleanly avoid (potentially
unnecessarily) caching column 4 if we are asked for column 3 then
column 5, just in case we are asked for column 4 later on, unless
we issue a specific "SELECT column4" later. But the latter would be
quite expensive in terms of app-to-database roudtripe times :-( and
thus creates another performance issue.
Change-Id: I999b3f8f0b8a215acb390ffefc839235346e8353
fixup of d4ae29a37873843c20fe7d5f5f071f8fb201fed9
after the call to m_pCacheSet->absolute_checked, the data *is* used,
so we cannot anymore exempt m_pCacheSet from giving correct data.
Change-Id: I7d3644ca08ce43cb030a80984605a1f8a8a64211
