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)
(earliest affected)
Hardware: All All
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: Database-Firebird-Migration
  Show dependency treegraph
Reported: 2018-05-04 23:43 UTC by Drew Jensen
Modified: 2019-05-07 16:14 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

test file (1.35 MB, application/vnd.oasis.opendocument.database)
2018-05-04 23:44 UTC, Drew Jensen
zip with test ODB and 3 image files (305.66 KB, application/zip)
2018-05-05 14:25 UTC, Drew Jensen

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
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:
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 
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 and 6.1alpha displaying the same tables information after use of the migration function here: https://nextcloud.documentfoundation.org/s/AMngzJjP94fcsbg sees the tables column as type text(fix)[CHAR]
6.1 alpha sees the tables column type as Image[BLOB]

The image controls, with 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.