Can't confirm the buggy behavior with LO 7.3.3.2, internal HSQLDB, on OpenSUSE 15.3 64bit rpm Linux.

Started a query like
--
SELECT * FROM "Table"

and content is shown well here.

Please add an example database for this.

(In reply to Robert Großkopf from comment #1)
> Can't confirm the buggy behavior with LO 7.3.3.2, internal HSQLDB, on
> OpenSUSE 15.3 64bit rpm Linux.
> 
> Started a query like
> --
> SELECT * FROM "Table"
> 
> and content is shown well here.
> 
> Please add an example database for this.

Your code is right for me here. But if I remove all comments then issue remains if I enclose the SELECT clause in another one , the same problem persist, one column display 0 not string:

SELECT * FROM (SELECT * FROM Table) AS L1

I check this code in PgAdmin4 and it works well, not with query in Libo Base.

For information the type of the column is TEXT but data inside is integer number with 13digits.

May be query engine interpret the data as integer according to the length or to the complexity of the code.

Listing data through 'Tables' menu works well.

Have tested this with a subquery as reported in comment2. Couldn't find any buggy behavior with an internal HSQLDB.
Then tested also with PostgreSQL (pgAdmin …) - same result with the direct connection.
How do you connect to PostgreSQL with LO Base?
Datataype "TEXT" → is it [VARCHAR]?

(In reply to Robert Großkopf from comment #3)
> Have tested this with a subquery as reported in comment2. Couldn't find any
> buggy behavior with an internal HSQLDB.
> Then tested also with PostgreSQL (pgAdmin …) - same result with the direct
> connection.
> How do you connect to PostgreSQL with LO Base?
> Datataype "TEXT" → is it [VARCHAR]?

For connection I did :
"Connect to an existing database" -> PostgreSql
"connection string" -> dbname=theDB hostaddr=127.0.0.1 port=5432 user=postgres

The faulty field is declared like this : cg TEXT NOT NULL,

(In reply to titanemdg from comment #4)
> 
> For connection I did :
> "Connect to an existing database" -> PostgreSql
> "connection string" -> dbname=theDB hostaddr=127.0.0.1 port=5432
> user=postgres
> 
> The faulty field is declared like this : cg TEXT NOT NULL,

Seem you are using the direct connection.
Have tested with direct connection:
Tools → SQL
CREATE TABLE public.COMPANY(
   ID INT PRIMARY KEY     NOT NULL,
   NAME           TEXT    NOT NULL,
   AGE            INT     NOT NULL,
   ADDRESS        CHAR(50),
   SALARY         REAL
);

Opened the table for input data and wrote in field name: '1.234567' (an in the other fields also some data)
Started query 
--
SELECT * FROM (SELECT * FROM "public"."company" ORDER BY "id") "company"

No problem with field name, set as TEXT, here. It will be shown in LO Base and pgAdmin. No '0' instead of '1.234567'.

I have created the table with libo base and tested column 'name' and 'address'.
Inserting and modifying  the 'Company' table was done with pgadmin4 GUI.
The code is :
SELECT * FROM (SELECT * FROM "public"."company" ORDER BY "id") "company"

TEST 1:
------------
Set
name = '1.234567'
address = '1.234567'

Result of the code in libobase are:
name -> '1,23'
address -> '1.234567'

TEST 2 :
--------------
Set
name = '1,234567'
address = '1,234567'

Result of code in libobase are:
name -> '1'
address -> '1,234567'


I am using french language settings

(In reply to titanemdg from comment #6)
> 
> TEST 1:
> ------------
> Set
> name = '1.234567'
> address = '1.234567'
> 
> Result of the code in libobase are:
> name -> '1,23'
> address -> '1.234567'

Seems the field "name" is formatted as number, see decimal separator ','. I couldn't format it as number here. Formatting is impossible in query here. Could only set horizontal align when connecting through direct connection with PostgreSQL …

Could reproduce the error.

If all entries in a TEXT field could also be recognized as a number the field will be formatted as a field for numbers in a query. It has nothing to do with direct SQL and starting with a comment.

SELECT * FROM (SELECT * FROM "public"."company") "company"

will reproduce the error directly. Has something to do with a query, which shows the content of a query. Seems the direct connection looses the information for the field and tries to detect it by the content of the column.