Bug Hunting Session
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: NEW
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: 2019-09-12 19:05 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


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.