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