and pass it to the parser and PredicateInput constructors.
This makes the whole story consistent; before system locale settings were already manually passed to parseNodeToPredicateStr, which led to some things being parsed as en_US and others as system locale.
Change-Id: Ib9571b10d79183571e8ab3f79660b41594dc2d1c
Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk
have kept them, in order not to break external API (the automatic using declaration
is LO-internal).
Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
.. to Reference<XComponentContext>
mostly in the dbaccess module, but it also affected some other
modules.
Change-Id: I09b3f6fe7a9b33498b11d98b5521b5aeeb8882be
Using the autocorrect list of LibreOffice
extras/source/autotext/lang/en-US/acor/DocumentList.xml
Change-Id: I8b93969bc0742c2e95b8b7db3c4c37691e8d3657
Script: http://pastebin.ca/2327716
The "sComposerFilter != m_sRowSetFilter" could not influence the result.
Proof.
The right hand-side of the || is evaluated only when m_sRowSetFilter.isEmpty()
So the only case where the removed test could have an influence is when
m_sRowSetFilter.isEmpty().
However, the right hand-side of the && is evaluated only when !sComposerFilter.isEmpty().
We have m_sRowSetFilter.isEmpty() and !sComposerFilter.isEmpty().
In particular, (sComposerFilter != m_sRowSetFilter) is true.
Qed.
Change-Id: I1484d78cf2d7a5e8ca44f382eb7c440c84d8c10e
Instead of playing tricks with parameters that when filled in force a part of the WHERE clause to have not influence, actually use several different statements and hardcode in each the kind of test to be done
Change-Id: I93e1978f0420bc627a02291f209c788b9b4f2e96
I have cleared out String and ::rtl::OUString calls in module dbaccess/source/core/misc.
It was mainly file dbaccess/source/core/misc/dnstypes.cxx , and it's usages. There are
still some calls in dbaccess for this class(ODnsTypeCollection), that needs refactoring
(eg. in file DbAdminImpl.cxx, method "String ODbDataSourceAdministrationHelper::getConnectionURL() const").
Remaining calls will be my next task (in module dbaccess). I also clear out deprecated macro
RTL_CONSTASCII_USTRINGPARAM every time I find one. The class I've mentioned above
(ODnsTypeCollector) is OK.
Change-Id: Ia0f3bb8cc649d1ecf8decc093f8a1a20ee23c33c
Reviewed-on: https://gerrit.libreoffice.org/2289
Reviewed-by: Andras Timar <atimar@suse.com>
Tested-by: Andras Timar <atimar@suse.com>
::rtl::OUString was replaced to OUString and all occurences of String was replaced to OUString in dbaccess/source/core/api
Change-Id: I9771708408e04dcebe18f49a75c83036740f0ca2
Reviewed-on: https://gerrit.libreoffice.org/2239
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
In the evolution address book where we have real column names of e.g.
first_name, second_name and city. On parsing via
OSQLParseTreeIterator::appendColumns that creates some labels using those real
names but the evo XResultSet gives them proper labels of First Name, Second
Name and City the munge means that here we have e.g. just "City" as a label
because it matches, while the others don't
The symptoms are to load the evolocal.odb and of the 128 columns column 5 is
repeated until 128
This is all a horrible confusing mess. It seems safest to catch the
mismatch of column counts and throw away the partial list and force
a generate of a full list.
Change-Id: I1d6e2a282bdd43acac63c366eb2a9d029aa17878
Also switch BOOLEAN constructor from sal_Bool to bool.
old/new signed/unsigned storage situation:
-------------------------------------------------------
SQL type | signed | unsigned old | unsigned new
-------------------------------------------------------
TINYINT | sal_Int8 | sal_Int16 | sal_uInt8
SMALLINT | sal_Int16 | sal_Int32 | sal_uInt16
INTEGER | sal_Int32 | sal_Int64 | sal_uInt32
BIGINT | sal_Int64 | pValue (String*) | sal_uInt64
-------------------------------------------------------
When sticking an UNSIGNED TINYINT into an Any,
silently promote it to UNSIGNED SMALLINT (that is sal_uInt16),
else Any would take it as a sal_Bool and normalise to
sal_True (1) or sal_False (0).
When constructing an ORowSetValue from a sal_Bool,
silently keep it as an unsigned 8 bit integer
(that is understand it as a sal_uInt8).
This will work in most cases,
since when asked back for a bool or sal_Bool,
we'll give back the right value.
Only code looking at the type tag could possibly
make a "wrong" decision.
The main (hopefully only?) path
through which this would happen is
through an implementation of
XParameters::setBoolean
XRowUpdate::updateBoolean
that would use its sal_Bool argument
to construct an ORowSetValue.
So make sure each implementation
constructs a proper BOOLEAN so as not to get confused.
For authorship/copyright purposes, this patch is a cooperation between
Lionel Elie Mamane <lionel@mamane.lu>
and
David Ostrovsky <david@ostrovsky.org>
Change-Id: I3f1f08716127147f077bff4edb6ec558b1b09e09
- Sanitized some OUStringBuilder, avoiding creating a new one and after
make some appends
- Removed some ::rtl prefixes
- Remove RTL_* macro
Change-Id: Ide3d78f20c68774cd4864b82cb8d29784228d1cd
Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/1552
Reviewed-by: Miklos Vajna <vmiklos@suse.cz>
Tested-by: Miklos Vajna <vmiklos@suse.cz>
This was done for the sake of ODBC,
but the cost was imposed on all backends.
The ODBC problems are now solved cleanly (and more efficiently)
in the SDBC<->ODBC layer.
Change-Id: Ib8a864da08deaaacc96a379fb72b3b7cbb34598c
For example dbaccess::OSingleSelectQueryComposer::appendOrderByColumn expects it
(via impl_getColumnName_throw via getTableAlias)
There is some vagueness:
Should the TableName property contain just the table name,
or the *composed* table name
(that is with catalog and/or schema if used by this DB)?
In the case of a query, should it contain the table name (alias)
*in* *the* *query* or of the original table?
In the former case, what meaning do SchemaName and CatalogName have?
They should be empty?
For now, commit as such and deal with the fallout, if any,
when it hits the fan.
If we really need to store these *different* values,
(that is, some code validly needs them)
it would be easier / cleaner / ...
to define *different* properties
for these *different* notions.
Change-Id: I032e619a60e7563cd51478db16cb5e0e5452bfde
Especially since the rest of the function is prepared to handle
no/empty (Catalog|Schema|Table)Name.
Change-Id: Ic0bb59ead5789e671c90887ef850588f4924f5e7
