[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libreoffice-users] Re: Form fields not filled


On Thu, 2019-07-18 at 10:48 +0200, Alexander Thurgood wrote:
> Le 18/07/2019 à 09:47, Harvey Nimmo a écrit :
>
> Hi Harvey,
>
> > I using LibreOffice (version 6.1.2.3) Base as client to a backend
> > Mariadb10 via MySQL(JDBC) connector.
> >
> > I have a created a Query in Base of the form SELECT * FROM
> > <tablename>
> > ORDER BY <Field1> ASC, <Field2> ASC
> >
>
> How did you create this query ? Sounds like you did this via the
> Query
> Designer GUI ?
>
> How is the query being executed ? Via the internal LO SQL parser
> (default when executing via Query Designer) or directly via the db
> engine (direct SQL button activated) ?
>
> FWIW, there are a few known issues between the MySQL (JDBC) Connector
> and a MariaDB backend when used in combination through LO.
>
> Have you tried using the MariaDB JDBC connector instead ?
>
>
> Alex
>
Hi Alex,

things have become a bit clearer now.

Yes, I created the query via the Base GUI. The query is called up by
Data control of the form.

OpenSUSE provides only the ODBC connector for mariadb, no JDBC
connector.

It is the behaviour of the GUI query editor that got me confused.

With the GUI query editor, I copied the entire table as <tablename>.*
into the query fields. I followed up by adding two of the table fields
to the query and selected 'ascending' for sorting for each of these 2
fields. I noticed then, that I could not deselect the 'Visible' flags
for these 2 sort fields. Why on earth not? The behaviour means that the
2 fields will each now appear twice when running the query. No wonder
then that the Form based on this query did not transfer the data from
those fields back to the table. It could not cope with the ambiguity

On inspecting the SQL text of the query, I was expecting a query of the
kind:
SELECT * FROM <tablename> ORDER BY <Field1> ASC, <Field2> ASC

What I saw was:

SELECT * <tablename>.*, <tablename>.<Field1>, <tablename>.<Field2> FROM
<schema>.<tablename> <tablename> ORDER BY <Field1> ASC, <Field2> ASC

After deleting the text ', <tablename>.<Field1>, <tablename>.<Field2>'
from the SQL query, the extra fields were not displayed on running the
query. But on saving the query again, the deleted text was added again,
and it's back to square one.

Is this a bug? It can't be right, that the 'Visible' flags of the extra
fields cannot be deselected. Obviously, the corresponding SQL queries,
with or without the flags are different giving different query results,
but the GUI behaviour forces only the one variant. Also, surely,
'hidden' behaviour, as happens to the SQL text by just saving the GUI
query without any changes must always be wrong.

Fortunately, I have the workaround of removing the sort fields from the
GUI query and adding them to the form.

Cheers
Harvey







--
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/users/
Privacy Policy: https://www.documentfoundation.org/privacy

Follow-Ups:
Re: [libreoffice-users] Re: Form fields not filledRobert Großkopf <robert@familiegrosskopf.de>
References:
[libreoffice-users] Form fields not filledHarvey Nimmo <harvey@nimmo.de>
[libreoffice-users] Re: Form fields not filledAlexander Thurgood <alex.thurgood@gmail.com>
Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.