Removes "virtualdbtools" and its implementation under "simpledbt", which are
mostly wrappers around various dbtools functions and classes, previously aiding
the now removed dynamic loading logic.
Removes IDataAccessTools, IDataAccessTypeConversion and IDataAccessToolsFactory
interfaces and their accompanying implementations which are completely unused.
Removes IDataAccessCharSet (implemented by ODataAccessCharSet) and moves the
implementation into a function which replaces ODataAccessCharsetHelper.
Removes ISQLParseNode and ISQLParser and their implementation in
OSimpleParseNode and OSimpleSQLParser, which simply wrap around OSQLParseNode
and OSQLParser respectively. To avoid including "sqlbison.hxx" unnecessarily,
includes to "sqlbison.hxx" are now only used where needed.
Change-Id: Id882dfbf43514d84a1eaffc1f916d627830c8cd6
Reviewed-on: https://gerrit.libreoffice.org/15450
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>
ie.
void f(void);
becomes
void f();
I used the following command to make the changes:
git grep -lP '\(\s*void\s*\)' -- *.cxx \
| xargs perl -pi -w -e 's/(\w+)\s*\(\s*void\s*\)/$1\(\)/g;'
and ran it for both .cxx and .hxx files.
Change-Id: I314a1b56e9c14d10726e32841736b0ad5eef8ddd
Patch by: hanya
Fixed date filter problems in table view. Now processes old style date format
and "normal" for database as expected.
(cherry picked from commit 79ff7fc76c74a012933230d6f3c37977eccc6398)
Conflicts:
dbaccess/source/core/api/SingleSelectQueryComposer.cxx
Change-Id: I2ae1b50b9e85ff2c543aaea90894a7edd5bc7524
Regression introduced with 03a2b4a80c5854bcb8520f2a43e485b98e3eba8f "fdo#82151
when constructing column object, replace m_aCurrentRow by a function," where
the other call to m_pGetValue in ORowSetDataColumn::fireValueChange appears OK,
as ORowSetBase::firePropertyChange already wraps the fireValueChange calls in a
try--catch.
Change-Id: I527cc35ae120cf083f7c69a9a23526839a2bbddb
Valgrind is capable of detecting such bugs. No need for extra macros.
Conflicts:
dbaccess/source/ui/dlg/tablespage.cxx
Change-Id: I25ea9174a042050efdb371246417ee7f2edae997
Reviewed-on: https://gerrit.libreoffice.org/7532
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Compiler plugin to replace with matching number(), boolean() or OUString ctor,
ran it, few manual tweaks, mark as really deprecated.
Change-Id: I4a79bdbcf4c460d21e73b635d2bd3725c22876b2
as opposed to *table* columns,
and notwithstanding HSQLDB 1.8 (our embedded database) bugs.
Actually, supporting ORDER BY on non-select (but table) columns is OPTIONAL for DBMSs
(but quite common)
Change-Id: I6725dfda36b09429a78262bff6f3d3e3dd9032b6
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
.. to Reference<XComponentContext>
mostly in the dbaccess module, but it also affected some other
modules.
Change-Id: I09b3f6fe7a9b33498b11d98b5521b5aeeb8882be
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
