Simple db with image field in table fails to work after migration to firebird.
Steps to Reproduce:
1.Download and open attached ODB
2.Open single form in file
3.When asked to start migration answer yes
4.migration routine finishes form opens no data in image controls, close the form
5 run the single report, no image data
image controls do not work for graphics stored in the database with firebird.
Both the form and report work as expected using the hsql engine and the same test 6.1 application
User Profile Reset: No
tested on build:
Build ID: f1579d3d6c5f5f3a651825e035b93bee7a4f43c6
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2;
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-05-03_10:04:51
Locale: en-US (en_US.UTF-8); Calc: group
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/65.0.3325.181 Chrome/65.0.3325.181 Safari/537.36
Created attachment 141899 [details]
Simple, 1 table, form and report
Could confirm the buggy behavior.
After migration with
CPU-Threads: 4; BS: Linux 4.4; UI-Render: Standard; VCL: kde4;
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-05-04_01:13:51
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group
I couldn't see any image in the imagecontrol of the form and there isn't any image available for the report.
Opening the *.odb-file shows a Firebird-database with nearly the same size as the HSQLDB-database. Seems there has been copied something from one to another, but it isn't displayable at this moment.
Created attachment 141907 [details]
zip with test ODB and 3 image files
OK - this file shows that the problem is only with images saved in the database table.
It is identical to the first test file but stores a URL (w/ relative addressing) to 3 images.
Unzip the file into a directory, open the test file fb_mig_image_url and open the form triggering the migration function. It will run to completion and both the form and report will display the images as expected.
The migration function is setting the wrong data type for hsql Image [ LONGVARBINARY ] and 6.1 is GUI is not recognizing the mistake.
You can see side by side screen shot of both the table design editor and the table data editor between 184.108.40.206 and 6.1alpha displaying the same tables information after use of the migration function here: https://nextcloud.documentfoundation.org/s/AMngzJjP94fcsbg
220.127.116.11 sees the tables column as type text(fix)[CHAR]
6.1 alpha sees the tables column type as Image[BLOB]
The image controls, with 18.104.22.168 and 6.1, work fine when the table is defined as type Blob[BLOB].
On pc Debian x86-64 with master sources updated yesterday, I reproduced this.
The weird thing is, when I open the first attachment and accept the FB migration, tst_data has type "Image[BLOB]" but I've got no images when opening form.
So, there is data being written for sure and it seems that the sdbc, I suppose, isn't handling something quite right with the data aware image control - so maybe this isn't an issue really.
I think I should try to read the data from firebird using as stream and see if maybe the intact images are there after all. I'll write back afterwards.
I noted that after migration from HSQLBD, images were transferred to an Image [BLOB] type of field. Data was not lost, but images would not show up in forms.
I found a workaround by copying the data into a new [BLOB] field (with a sql query UPDATE "photos_table" SET "Photo2" = "Photo") and it worked. The pictures appear using this new field.
Then I did some copying of table and data to recover the same field name so that the form(s) would not need any change.
(In reply to Silvain Dupertuis from comment #7)
> I noted that after migration from HSQLBD, images were transferred to an
> Image [BLOB] type of field. Data was not lost, but images would not show up
> in forms.
> I found a workaround by copying the data into a new [BLOB] field (with a sql
> query UPDATE "photos_table" SET "Photo2" = "Photo") and it worked. The
> pictures appear using this new field.
> Then I did some copying of table and data to recover the same field name so
> that the form(s) would not need any change.
Have tried this. Table editor will try to change the field for BLOB every time I am editing the table. Here I have to choose "No - don't change". But when setting the new format for the image-field to BLOB[BLOB]-field the content will be shown.
Created attachment 154142 [details]
Image scenario on a Firebird embedded database
The migration might work - or might not work. It seems to me that this functionality does not work even with pure Firebird - without migration:
- Create Firebird embedded database
- Create table with an integer and an image
- Create form (with wizard), insert some data.
- Create report (with wizard), try to have a look at the images.
Expected result: I should be able to see the images I inserted.
Actual result: No images, only a 'broken image' symbol.
(In reply to Tamas Bunth from comment #9)
> Created attachment 154142 [details]
> Image scenario on a Firebird embedded database
> The migration might work - or might not work. It seems to me that this
> functionality does not work even with pure Firebird - without migration:
> - Create Firebird embedded database
> - Create table with an integer and an image
> - Create form (with wizard), insert some data.
> - Create report (with wizard), try to have a look at the images.
> Expected result: I should be able to see the images I inserted.
> Actual result: No images, only a 'broken image' symbol.
On pc Debian x86-64 with master sources updated today or with LO Debian package 22.214.171.124, I don't reproduce this part, I suppose it corresponded to tdf#121886
Drew: could you give a try with a recent LO version (7.0.4 min)?
Indeed, I gave a try with your first attachment and don't reproduce this with LO Debian package 7.0.4 or with master sources updated today.
Of course, have in mind that migration tool can't be considered as reliable, that's why it's still considered as experimental.
Dear Drew Jensen,
This bug has been in NEEDINFO status with no change for at least
6 months. Please provide the requested information as soon as
possible and mark the bug as UNCONFIRMED. Due to regular bug
tracker maintenance, if the bug is still in NEEDINFO status with
no change in 30 days the QA team will close the bug as INSUFFICIENTDATA
due to lack of needed information.
For more information about our NEEDINFO policy please read the
wiki located here:
If you have already provided the requested information, please
mark the bug as UNCONFIRMED so that the QA team knows that the
bug is ready to be confirmed.
Thank you for helping us make LibreOffice even better for everyone!
No repro with
Version: 126.96.36.199 / LibreOffice Community
Build ID: 85f04e9f809797b8199d13c421bd8a2b025d52b5
CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Using the first test file, the migration completes and I can see the images when I navigate through the records via the form.
Also tested adding a new image record, this was saved and displayed.
The report also displayed the images.
I would be inclined to mark this as WFM.
(In reply to Alex Thurgood from comment #13)
> No repro with
> Version: 188.8.131.52 / LibreOffice Community
> Build ID: 85f04e9f809797b8199d13c421bd8a2b025d52b5
> CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx
> Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
> Calc: threaded
> Using the first test file, the migration completes and I can see the images
> when I navigate through the records via the form.
> Also tested adding a new image record, this was saved and displayed.
> The report also displayed the images.
> I would be inclined to mark this as WFM.
Have tested with LO 184.108.40.206: No Images could be seen in the form.
Then tested with LO 220.127.116.11: Images could be seen.
All Test made with OpenSUSE 64bit rpm Linux.
So something has been changed and the buggy behavior has been gone.
I will set this one to WORKSFORME.