Same here, using 
Version: 7.3.6.2 / LibreOffice Community
Build ID: c28ca90fd6e1a19e189fc16c05f8f8924961e12e
CPU threads: 16; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb)
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded
on
Operating System: Manjaro Linux
KDE Plasma Version: 5.26.5
KDE Frameworks Version: 5.102.0
Qt Version: 5.15.8
Kernel Version: 5.15.91-1-MANJARO (64-bit)

I have an existing table, not created with BASE but directly in PostgresSQL, having fields type TEXT. Browsing through a form, based on a quite complex query from that table, with native Connector produces data-losses, as the original content is replaced by '0'. With JDBC-Connector everything is fine.

I don't seem to be able to reproduce this on

Version: 7.4.4.2 / LibreOffice Community
Build ID: 85569322deea74ec9134968a29af2df5663baa21
CPU threads: 8; OS: Mac OS X 13.0.1; UI render: Skia/Raster; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded

@Robert :

can you explain what would be a typical sequence of characters for your varchar field so that I can try and reproduce ?

Is the varchar field also the primary key field, or do you have a separate INT field for that ?

I set up my table as follows :

                       Table "public.SportClub"
   Column   |          Type          | Collation | Nullable | Default 
------------+------------------------+-----------+----------+---------
 ID         | integer                |           | not null | 
 ClubName   | character varying(100) |           |          | 
 Country_ID | integer                |           |          | 
Indexes:
    "SportClub_pkey" PRIMARY KEY, btree ("ID")

The primary key directive was added to the table definition via the LO UI (Edit Table) after I had initially defined the table without a PK.

Ah, I've just noticed you mentioned MEMO fields and not VARCHAR.
Will test again, sorry.

(In reply to Alex Thurgood from comment #4)
> Ah, I've just noticed you mentioned MEMO fields and not VARCHAR.
> Will test again, sorry.

Hmm, still no repro with just :

ID INT(4) NOT NULL
Name MEMO (text)

even if I enter a number into the sequence of characters (at end or beginning) into the MEMO field.


Note : when I choose MEMO (text) from the LO UI dropdown in table design, it gets converted to 

character varying (100) in the postgres database (postgres 10).

(In reply to Alex Thurgood from comment #5)
> 
> 
> Note : when I choose MEMO (text) from the LO UI dropdown in table design, it
> gets converted to 
> 
> character varying (100) in the postgres database (postgres 10).

It is created here as field type TEXT.
ProstgreSQL 13.9 is the database server here.

Datatype TEXT should also be there in PostgreSQL 10.

Where did you get the information it has been changed to character varying (100)? I get the information it is "TEXT" when opening the table for editing in dBeaver.

(In reply to Robert Großkopf from comment #6)

 
> Where did you get the information it has been changed to character varying
> (100)? I get the information it is "TEXT" when opening the table for editing
> in dBeaver.

From a postgres console session, using 

\d "TABLENAME"


I tried to create a new table via the LO GUI, and chose MEMO (text) when defining the character field, with an ID INT (4) field as the NON NULL PK.

When I query the table definition from the console, I get :

\d "Pets"
                Table "public.Pets"
 Column |  Type   | Collation | Nullable | Default 
--------+---------+-----------+----------+---------
 ID     | integer |           | not null | 
 Pet    | text    |           |          | 
Indexes:
    "Pets_pkey" PRIMARY KEY, btree ("ID")




I still can't reproduce the problem.

Could this be a difference between PG10 and PG13 ?

(In reply to Alex Thurgood from comment #7)
> (In reply to Robert Großkopf from comment #6)

Hi Alex,
>                 Table "public.Pets"
>  Column |  Type   | Collation | Nullable | Default 
> --------+---------+-----------+----------+---------
>  ID     | integer |           | not null | 
>  Pet    | text    |           |          | 
> Indexes:
>     "Pets_pkey" PRIMARY KEY, btree ("ID")

This should be the right definition. If I define this in LO GUI with direct connection and try to input text I always get '0'. I only could input numbers.
If there is text in field "Pet" (while inserting by a JDBC-connection) I could also insert text.
> 
> Could this be a difference between PG10 and PG13 ?

Might be it is a difference between 10 and 13, but the type "text" in PostgreSQL is very old …

> Could this be a difference between PG10 and PG13 ?


Well, I fired up a PG15 instance, and then could reproduce the problem as described.

It sounds like the SDBC driver would need to be built against a more current release of postgres than PG10.

Adjusting title.

@lionel, @julien : would you happen to know which version of postgres our SDBC driver is built against ?

(In reply to Alex Thurgood from comment #9)
> > Could this be a difference between PG10 and PG13 ?
> 


Note that the title only reflects current testing.

Robert reported against PG13
I reproduced against PG15
I did not reproduce against PG10.

It turns out that postgres 10 was EOL in November 2022:
https://endoflife.date/postgresql

if we haven't done so, I guess the driver should be updated to something current and not nearing EOL, as even v11 is EOL in 8 months time.

(In reply to Alex Thurgood from comment #9)
> > Could this be a difference between PG10 and PG13 ?
> ...
> @lionel, @julien : would you happen to know which version of postgres our
> SDBC driver is built against ?

taking a look at download.lst, I see:
    464 POSTGRESQL_TARBALL := postgresql-13.8.tar.bz2
(see https://opengrok.libreoffice.org/xref/core/download.lst?r=3c988ef4#464)

so I'd say Postgresql 13.8

It migrated from 9.2 to 13.1 with 234833f7823a1424b62c93e145f0cfe2c6b6efd5
(see https://cgit.freedesktop.org/libreoffice/core/commit/?id=234833f7823a1424b62c93e145f0cfe2c6b6efd5)

you can see the migrations to 13.5 and 13.8 with https://cgit.freedesktop.org/libreoffice/core/log/?qt=grep&q=postgresql

Have tested this a little bit more.

Bug will only appear if primary key is a numeric field (int 4). If primary key is varchar(100) text content is saved in field for Meme[text] as text.

Bug will only appear directly after creating the table. If you close the database file, close and reopen LO and connect again to PostgreSQL with direct connection text content will be saved.

Alex, you marked as a regression, but Michael in Comment 1 reproduced in 7.3.
Any evidence that this is actually a regression?

@Stephane - probably because I couldn't reproduce the buggy behaviour against a pg10 instance, cf. comment 5.

It was only when I tried against a pg13 instance and later that I saw the problem.

I thought that it might possibly be down to a change introduced in the TEXT datatype in pg13, but couldn't see anything in the release notes that might be indicative of such a change.

I can't test any 6.x on macOS Arm, they refuse to run.

Ideally, someone should test with a 6.x against at least a pg13 instance on Linux.

I get "permission denied" errors when creating the table in LO 6.0 or 6.4.

Making sure the primary key was Integer[int4] before the Memo[text] var, I could reproduce with PG13.10 and:

Version: 7.3.7.2 / LibreOffice Community
Build ID: e114eadc50a9ff8d8c8a0567d6da8f454beeb84f
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

For people not reproducing with PG10, maybe double-check that you had it setup as Robert described in Comment 13.

Works as expected in:

Version: 7.2.7.2 / LibreOffice Community
Build ID: 8d71d29d553c0f7dcbfa38fbfda25ee34cce99a2
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

So regression.

tried to bibisect but couldn't reproduce in the bibisect repo, then tried again to reproduce in 7.3.7.2 where I reproduced before, and couldn't reproduce either.

I used a new table every time, and made sure a primary int4 ID was before the memo[text]var, no luck. I think I need more precise steps...

1. Table has to be created with 2 fields, 
"ID" INTEGER[int 4]
"Memotext" MEMO[Text]
"ID" should be primary key

2. Try to input in GUI: "ID" → 1, "MemoText" → 'New Text'

3. Go to next row. 'New Text' will be set as '0'.

All this only happens after creating a new table here. Doesn't happen after closing the connection and reopening the connection.

All this happens only if there are other tables in schema "public". If there is no table in schema "public" the first table won't show this bug here.

Tested with PostgreSQL 14.7 on OpenSUSE 15.4 64bit rpm Linux.
Bug appears in LO 7.0.5.2, also in LO 7.5.1.2 and all other versions installed here.
Think this isn't a regression, has never worked and was never detected …

Another hint: Seems to be a problem with more than on the field type "text". 
'0' appears also in field type array if table has been created new.

Created a array in this way through Tools → SQL
CREATE TABLE "public"."Table_Ar" ("ID" int4 NOT NULL,"Surname" varchar(100),"Forename" varchar(200)[], PRIMARY KEY  ("ID"));

I'm not able to enter data in the array in the fresh table. It will produce '0' and this won't be accepted by an array, because it needs {…}.

When inserting through Tools → SQL

INSERT INTO "public"."Table_Ar" ("ID", "Surname", "Forename") VALUES (1, 'Müller', '{Liese, Gerd}');

The row will be inserted and the next row could be created in GUI without any problem.

Couldn't reproduce the bug with
Version: 25.2.2.1 (X86_64) / LibreOffice Community
Build ID: 38d746d66d9b82fa248a2e90142b9dd3ddd1d6cd
CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb)
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded
and Postgres 17

I will set this one to WORKSFORME

Created attachment 200307 [details]
SQL script to delete and initialize the database

Attached file dbdump is sql script to delete and initialize the
database.

STR, short version
  - Create database.
  - Create .odb file.
  - Enter a row in existing table.  The memo is saved as entered.
  - Create a table.
  - Enter a row in new table.  The memo is zeroed.

STR, longer version.  Note that for ease of reading, I am introducing
whitespace in strings to be typed; where a space is required, I say
"<space>".

( 1) Create a database and schema as per attached sql script dbdump.

( 2) Create and open a .odb connecting to that database.

( 3) At database window, type "<alt>+A" to display list of tables.
     Lower right pane shows schemas bug_153431, information_schema,
     and pg_catalog; bug_153431 is expanded showing table c00_empty.

( 4) Double-click table c00_empty.  Program presents window Table Data
     View with no data; caret is in first row in column id.

( 5) Type "1 <tab> abcde <space> fghij <tab>".  Caret moves to second
     row.  the_memo in first row shows "abcde fghij"; this is good.

( 6) Type "<ctrl>+W".  Program closes Data View and returns focus to
     database window.

( 7) In database window, in pane Tasks (upper right), click <Create
     Table in Design View>.  Program presents window Table Design.

( 8) Type "<tab>".  Caret is in column Field Name in first row.

( 9) Type "id <tab> int <tab> <tab>".  Caret moves to second row.

(10) Type "the_memo <tab> m <tab> <tab>".  Caret moves to third row.
     The window now shows

         Field Name  |  Field Type
         ------------+------------------
         id          |  Integer [ int4 ]
         the_memo    |  Memo [ text ]

(11) Right-click row header for id and from the drop-down menu select
     Primary Key.  The row header for id now shows a key-icon.

(12) Type "<ctrl>+W".  Program presents dialog "Do you want to save the
     changes?".

(13) Type "<alt>+Y".  Program presents dialog "Save As"; focus is on
     Table Name, which shows value Table1.

(14) Type "<shift>+<tab> <shift>+<tab>".  Focus moves to Schema, which
     shows value public.

(15) Type "b".  Program supplies value bug_153431.

(16) Type "<Enter>".  Program closes "Save As" dialog and returns focus
     to database window; lower right pane now shows that bug_153431
     contains Table1.

(17) In database window, in lower right pane, double-click <Table1>.
     Program displays Table Data View; caret is in first row in column
     id.

(18) Type "1 <tab> klmno <space> pqrst".  Caret is in first row in
     column the_memo at the end of the string you just typed.  So far,
     so good.

(19) Type "<tab>".  Caret moves to second row column id.  The value in
     first row column the_memo is zero.  This is bad.


I see this behaviour most recently in a localbuild of commit af3f54e7,
2025-04-09, configured ...

    --with-vendor=Terrence Enger
    --with-jdk-home=/usr/lib/jvm/default-java --enable-split-debug
    --enable-gdb-index --enable-ld=gold --enable-option-checking=fatal
    --enable-dbgutil --enable-debug --without-system-postgresql
    --without-myspell-dicts --with-extra-buildid --without-doxygen
    --with-external-tar=/home/terry/lo_hacking/git/src
    --without-package-format --enable-odk --disable-ldap
    --disable-skia --enable-python=fully-internal --disable-pdfium

and running on debian-sid.  I have seen it in other versions of
LibreOffice, but all running on debian.

The STR tolerate a little bit of fat-fingering, but all this is the
way I have been able to provoke the bug consistently.  Obviously there
is no good reason for entry of a row into c00_empty to change the
result in Table1.

I am setting bug status back to NEW.

I see that step (5) in the preceding STR is not needed.

Robert, what do these STR do for you?  If bug is not happening for you,
I have to suspect a difference in our environments.  What is your
environment?  How can I help?