Bug 117435 - Firebird: Migration: data type Image [ LONGVARBINARY ] is not being migrated properly
Summary: Firebird: Migration: data type Image [ LONGVARBINARY ] is not being migrated ...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
6.1.0.0.alpha1+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Database-Firebird-Migration
  Show dependency treegraph
 
Reported: 2018-05-04 23:43 UTC by Drew Jensen
Modified: 2021-09-18 03:27 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
test file (1.35 MB, application/vnd.oasis.opendocument.database)
2018-05-04 23:44 UTC, Drew Jensen
Details
zip with test ODB and 3 image files (305.66 KB, application/zip)
2018-05-05 14:25 UTC, Drew Jensen
Details
Image scenario on a Firebird embedded database (46.65 KB, application/vnd.oasis.opendocument.database)
2019-09-12 19:05 UTC, Tamas Bunth
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Drew Jensen 2018-05-04 23:43:29 UTC
Description:
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



Actual Results:  
image controls do not work for graphics stored in the database with firebird.


Expected Results:
Both the form and report work as expected using the hsql engine and the same test 6.1 application


Reproducible: Always


User Profile Reset: No



Additional Info:
tested on build:
Version: 6.1.0.0.alpha1+
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
Comment 1 Drew Jensen 2018-05-04 23:44:27 UTC
Created attachment 141899 [details]
test file

Simple, 1 table, form and report
Comment 2 Robert Großkopf 2018-05-05 08:04:23 UTC
Could confirm the buggy behavior.
After migration with 
Version: 6.1.0.0.alpha1+
Build-ID: 4ed3137022efa6128ad146e4b4dfae13548431dc
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.
Comment 3 Drew Jensen 2018-05-05 14:25:07 UTC
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.
Comment 4 Drew Jensen 2018-05-05 19:10:11 UTC
Changed summary

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 6.0.3.2 and 6.1alpha displaying the same tables information after use of the migration function here: https://nextcloud.documentfoundation.org/s/AMngzJjP94fcsbg

6.0.3.2 sees the tables column as type text(fix)[CHAR]
6.1 alpha sees the tables column type as Image[BLOB]

The image controls, with 6.0.3.2 and 6.1, work fine when the table is defined as type Blob[BLOB].
Comment 5 Julien Nabet 2018-06-10 19:19:07 UTC
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.
Comment 6 Drew Jensen 2018-12-03 17:12:59 UTC
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.
Comment 7 Silvain Dupertuis 2019-05-07 16:14:44 UTC
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.
Comment 8 Robert Großkopf 2019-06-15 18:26:25 UTC
(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.
Comment 9 Tamas Bunth 2019-09-12 19:05:18 UTC
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.
Comment 10 Julien Nabet 2021-03-20 11:40:57 UTC
(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 7.0.4.2, I don't reproduce this part, I suppose it corresponded to tdf#121886
Comment 11 Julien Nabet 2021-03-20 11:48:12 UTC
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.
Comment 12 QA Administrators 2021-09-17 03:51:29 UTC Comment hidden (obsolete)
Comment 13 Alex Thurgood 2021-09-17 08:09:24 UTC
No repro with 

Version: 7.1.5.2 / 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.
Comment 14 Robert Großkopf 2021-09-17 15:51:27 UTC
(In reply to Alex Thurgood from comment #13)
> No repro with 
> 
> Version: 7.1.5.2 / 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 6.1.5.2: No Images could be seen in the form.
Then tested with LO 7.2.0.4: 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.
Comment 15 QA Administrators 2021-09-18 03:27:51 UTC
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:
https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO

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!

Warm Regards,
QA Team

MassPing-NeedInfo-Ping