Created attachment 149696 [details] Assign Columns dialog I usually populate my HSQLDB table by copying data from a Calc table. I do so by selecting Paste > Append data. I haven't had any problems with this until updating the LibreOffice to the latest version (6.2.0.3). In Assign Columns dialog, the field values from source table show up truncated. The assignment works fine, though.
Created attachment 149697 [details] Calc table sample
In previous versions of LibreOffice, it would have showed this: Source table: 600 FOOBAR FOOBAR FOOBAR FOOBAR 1,5 73261900
Created attachment 149699 [details] Example-database and Calc file to try the import of data Can't confirm the buggy behaviour with LO 6.2.0.3 on OpenSUSE 15 64bit rpm Linux. The values of the first row are shown in the import-wizard here.
With database of Robert, If I accept to migrate to Firebird embedded I encounter the problem described in bug 123591 : "Seems Base/Firebird doesn't recognize the decimalseparator from the Calc-import-file". If I don't accept to migrate, I obtain this error message when I try to open database : Impossible d'établir la connexion à la source de données "import". file input/output error: C:\Users\bernard\Desktop\import.odb.log Bernard
(In reply to ribotb from comment #4) > With database of Robert, If I accept to migrate to Firebird embedded I > encounter the problem described in bug 123591 : "Seems Base/Firebird doesn't > recognize the decimalseparator from the Calc-import-file". Please don't mix this with Firebird bugs. It is reported as HSQLDB bug. The migration dialogue would only appear with experimental functions switched to 'on'. Set this off and try it with the original database again. You have to mark the content of Calc table, copy this and then directly insert this content to Base table.
Tried the example (HSQLDB embedded database) provided by Robert and it works OK. However, I am using 'split' database mode (sorry for not mentioning that above). I will create a new example database and see if the problem persists. I'll report back ASAP.
Created attachment 149722 [details] Assign columns Yep.. the problem appears to be related to the split database mode. When using it, the values of the first row truncate and/or show wrongly. Using an embedded HSQLDB database, the issue won't occur.
(In reply to Robert Großkopf from comment #5) > (In reply to ribotb from comment #4) > > With database of Robert, If I accept to migrate to Firebird embedded I > > encounter the problem described in bug 123591 : "Seems Base/Firebird doesn't > > recognize the decimalseparator from the Calc-import-file". > > Please don't mix this with Firebird bugs. It is reported as HSQLDB bug. The > migration dialogue would only appear with experimental functions switched to > 'on'. > Sorry!
@lnwalker : the problem is that there aren't many people in Base-QA using split-mode hsqldb - I dont' have any on macOS because pointing to a separate hsqldb.jar has had various nefarious consequences in the past including not being able to open normal previously created embedded hsqldb files, to the point where I no longer test such a db configuration.
@Drew, any chance you could bisect this issue ?
I can't reproduce it in Version: 6.4.0.0.alpha0+ Build ID: d4a70ecf61b016a32caef015eea127d13b357cf7 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: x11; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded Dear Reporter, Could you please paste the info from Help - about LibreOffice ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the information has been provided
Created attachment 153261 [details] How it looks for me in master
OK. I've done further tests and can confirm that the problem is resolved. BUT, I had to recreate a new database file (.odb) and start using it. With the old database file (.odb) that issue reported happened all the time. I don't know why and if that makes sense, since I always worked on that file and saved it regularly. Remembering that I'm using a split database. I've run into some crashes with Base, but I am going to report that in another thread. Using: Version: 6.3.0.4 (x86) Build ID: 057fc023c990d676a43019934386b85b21a9ee99 CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; Locale: pt-BR (pt_BR); UI-Language: en-US Calc: threaded
Setting to RESOLVED WORKSFORME as the commit fixing this issue hasn't been identified.