Bug Hunting Session
Bug 121886 - Firebird: Datatype Image(BLOB) is not working properly with Form or Report image controls.
Summary: Firebird: Datatype Image(BLOB) is not working properly with Form or Report im...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.4.7.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 127059 (view as bug list)
Depends on:
Blocks: Database-Firebird-Default
  Show dependency treegraph
 
Reported: 2018-12-03 17:05 UTC by Drew Jensen
Modified: 2019-09-15 20:06 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Example db (1.35 MB, application/vnd.oasis.opendocument.database)
2018-12-03 17:05 UTC, Drew Jensen
Details
Symbols backtrace for crash when attempting to open report (8.39 KB, text/plain)
2018-12-06 08:16 UTC, Alex Thurgood
Details
Screen shot of report (120.00 KB, image/png)
2018-12-07 14:47 UTC, Drew Jensen
Details
Example with 3 blob data types (1.17 MB, application/vnd.oasis.opendocument.database)
2019-06-16 20:57 UTC, Drew Jensen
Details
bt with debug symbols (11.50 KB, text/plain)
2019-09-15 20:06 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Drew Jensen 2018-12-03 17:05:48 UTC
Created attachment 147248 [details]
Example db

The attached file was started with Ubuntu 18.04 and LO 6.3Alpha0 and confirmed back to 5.4.

Single table (ID identity, image Image(BLOB), path varchar(255))
Single form with an image control for image and path
Single query which counts null image fields
Single report which uses image controls to print both image and path fields

To reproduce:

1 - download an open attached odb file
2 - open the single table first and empty it
3 - close the table open the form
4 - add a first record using the context menu for both image controls.
5 - click on the save record button

image disappears from the control linked to image but not path  

6 - add a second record
7 - only insert value for the path field (image control on right)
8 - click on save record, close the form
9 - run the query

The count is one, the data for the image seems to have been written to the table for the first record.

10 - close the query
11 - run the report

The output should be of both linked images and read errors for both the null (second) and not null image field (first record).

Expected behavior:
The image controls should be able to display data from Image(BLOB) fields.
Comment 1 Alex Thurgood 2018-12-04 09:04:40 UTC
@Drew : is this not a DUP of bug 117435 ?
Comment 2 Alex Thurgood 2018-12-04 09:07:47 UTC
See for example:

http://hsqldb.org/doc/guide/sqlgeneral-chapt.html#sgc_binary_types

LONGVARBINARY and BLOB are synonyms for the same data type, unless:

"You can set LONGVARBINARY to map to BLOB, with the sql.longvar_is_lob connection property or the SET DATABASE SQL LONGVAR IS LOB TRUE statement."
Comment 3 Alex Thurgood 2018-12-04 09:12:09 UTC
Ah, my bad, perhaps, I saw you mention LO5.4 and assumed that these tests were done with a hsqldb ODB file instead of against Firebird. In that case, probably not relevant.
Comment 4 Drew Jensen 2018-12-05 17:20:03 UTC
(In reply to Alex Thurgood from comment #3)
> Ah, my bad, perhaps, I saw you mention LO5.4 and assumed that these tests
> were done with a hsqldb ODB file instead of against Firebird. In that case,
> probably not relevant.

If I have it correctly, which I think I do, when 5.4 shipped the driver did not support creating the type with the GUI controls, the backend (fb engine) did but even that may of been an earlier version then the 3.0 used now. HSQL has no problem with either embedded images or then MEMO(LONGVARCHAR with a length of 2gig) data types and the test file was firebird created with the later LO version.

Firebird supports a varchar no longer than 32K bytes (with the number of characters available for storage dependent on the number of bytes needed to save a character for the selected character set). Does have a blob sub_type of text and that is the CLOB(BLOB) type. That seems to work fine with the UI controls in forms but not in ReportBuilder, but there is a workaround for retrieving the first 32k bytes worth of text by casting the column to type varchar in the result set fed to the report engine.

This issue with Image(BLOB) datatype and image controls would not be a duplicate of that IMO.
Comment 5 Alex Thurgood 2018-12-06 08:15:12 UTC
(In reply to Drew Jensen from comment #0)


> To reproduce:
> 
> 1 - download an open attached odb file
> 2 - open the single table first and empty it

How do I do that via the GUI ? The only way I can achieve this is if I execute the DELETE FROM command from Tools > Options > SQL


> 3 - close the table open the form
> 4 - add a first record using the context menu for both image controls.
> 5 - click on the save record button
> 
> image disappears from the control linked to image but not path  
> 

Confirming.


> 6 - add a second record
> 7 - only insert value for the path field (image control on right)
> 8 - click on save record, close the form
> 9 - run the query
> 
> The count is one, the data for the image seems to have been written to the
> table for the first record.

Confirming.


> 
> 10 - close the query
> 11 - run the report
> 
> The output should be of both linked images and read errors for both the null
> (second) and not null image field (first record).
> 

When attempting to run the report on master, I get the following error message:
"Internal error."
"An uncaught exception has occurred. Choose "Continue" to proceed with execution of the application in an unstable state. Choose "Force Quit" to halt the application and file a bug using the crash reporter. If you choose "Force Quit", any unsaved data will be lost."

If I choose "Continue", the report window opens, but isn't drawn or filled with any objects. This window then becomes unresponsive, remains in focus, and can not be removed, other than by forcing quit the LO application.


Tested with

Version: 6.3.0.0.alpha0+
Build ID: 284dd58e326e61a5d84bde367e1e4873dd738c76
CPU threads: 4; OS: Mac OS X 10.14.1; UI render: default; VCL: osx; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2018-11-22_23:09:13
Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US
Calc: threaded
Comment 6 Alex Thurgood 2018-12-06 08:16:31 UTC
Created attachment 147310 [details]
Symbols backtrace for crash when attempting to open report
Comment 7 Drew Jensen 2018-12-07 14:34:05 UTC
(In reply to Alex Thurgood from comment #5)
> (In reply to Drew Jensen from comment #0)
> 
> 
> > To reproduce:
> > 
> > 1 - download an open attached odb file
> > 2 - open the single table first and empty it
> 
> How do I do that via the GUI ? The only way I can achieve this is if I
> execute the DELETE FROM command from Tools > Options > SQL

FYI - with the Table view open use the mouse to select the entire table. Which you can do simply by clicking in the upper right hand corner of the grid (just to the left of the first column name). Then click delete. Done.

> 
snip
> 
> > 
> > 10 - close the query
> > 11 - run the report
> > 
> > The output should be of both linked images and read errors for both the null
> > (second) and not null image field (first record).
> > 
> 
> When attempting to run the report on master, I get the following error
> message:
> "Internal error."
> "An uncaught exception has occurred. Choose "Continue" to proceed with
> execution of the application in an unstable state. Choose "Force Quit" to
> halt the application and file a bug using the crash reporter. If you choose
> "Force Quit", any unsaved data will be lost."
> 
> If I choose "Continue", the report window opens, but isn't drawn or filled
> with any objects. This window then becomes unresponsive, remains in focus,
> and can not be removed, other than by forcing quit the LO application.
> 
> 
> Tested with
> 
> Version: 6.3.0.0.alpha0+
> Build ID: 284dd58e326e61a5d84bde367e1e4873dd738c76
> CPU threads: 4; OS: Mac OS X 10.14.1; UI render: default; VCL: osx; 
> TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2018-11-22_23:09:13
> Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US
> Calc: threaded

This could be a new issue perhaps - I'll try to duplicate that with 6.3.
Comment 8 Drew Jensen 2018-12-07 14:34:59 UTC
(In reply to Drew Jensen from comment #7)
> (In reply to Alex Thurgood from comment #5)
> > (In reply to Drew Jensen from comment #0)
> > 
> > 
> > > To reproduce:
> > > 
> > > 1 - download an open attached odb file
> > > 2 - open the single table first and empty it
> > 
> > How do I do that via the GUI ? The only way I can achieve this is if I
> > execute the DELETE FROM command from Tools > Options > SQL
> 
> FYI - with the Table view open use the mouse to select the entire table.
> Which you can do simply by clicking in the upper right hand corner of the
> grid (just to the left of the first column name). Then click delete. Done.
> 

Gees I even get that wrong - click in the upper left hand corner of the grid ;)
Comment 9 Drew Jensen 2018-12-07 14:47:38 UTC
Created attachment 147349 [details]
Screen shot of report

Regarding the crash with running the report - I was not able to confirm that with Ubuntu 18.04 and Version: 6.3.0.0.alpha0+
Build ID: d8d231f97d829350d965105e3a5be119d1a6494c
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-11-30_00:14:18
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

Attached report from two records, one has data in the Image column and the other is null, both records have a valid path to an image in the Path column. 

Perhaps it is a Mac issue?
Comment 10 Robert Großkopf 2019-02-10 08:06:18 UTC
I have tested this one with another database and some photos. The database will blow up to over 20MB so the images seem to be saved, but the images aren't shown in the control.

Test with LO 6.1.5.2, OpenSUSE 15 64bit rpm Linux
Comment 11 Robert Großkopf 2019-06-16 16:04:34 UTC
Images are only shown in the control with BLOB[BLOB]-fields, not with Image[BLOB] fields. It's the same reason as for bug 117435. Doesn't know why there is a field Image[BLOB] at all. Should be removed and the trouble will go away for these two bugs.
Comment 12 Drew Jensen 2019-06-16 18:42:31 UTC
(In reply to Robert Großkopf from comment #11)
> Images are only shown in the control with BLOB[BLOB]-fields, not with
> Image[BLOB] fields. It's the same reason as for bug 117435. Doesn't know why
> there is a field Image[BLOB] at all. Should be removed and the trouble will
> go away for these two bugs.

There is an Image[Blob] data type because for modern RDBMSs there are at least 3 types of blobs; basic binary, subtype image, subtype text.

Base being a front end tool and not a database per se (ODF spec) should recognize the three different types and work with them appropriately.

With HSQLdb embedded for example the three blob subtypes are represented as Image(Blob), Memo(Text) and Other.

With the Firebird embedded they are Blob[Blob], Image[Blob] and CLOB[Blob]. 

Images[Blob] is not being properly handled by the sdbc driver as evidenced in the forms and reportbuilder problems.

For that matter Clob is also not handled properly by forms, and will not allow the report wizard to finish if the user tries to insert an Clob field on a form. Reportbuilder also fails to recoginize it.

Clob data types are also not being handled therefore properly by the sdbc code.

Also, using Blob[Blob] datatype for image data, with the 6.3 firebird sdbc allow images to be used and displayed in forms but does nothing to help with Reportbuilder. The reportbuilder code will add any Blob[Blob] field as a Formatted Field in the form, not an image to be displayed.
Comment 13 Drew Jensen 2019-06-16 18:45:45 UTC
(In reply to Drew Jensen from comment #12)
> (In reply to Robert Großkopf from comment #11)
> > Images are only shown in the control with BLOB[BLOB]-fields, not with
> > Image[BLOB] fields. It's the same reason as for bug 117435. Doesn't know why
> > there is a field Image[BLOB] at all. Should be removed and the trouble will
> > go away for these two bugs.
> 
> There is an Image[Blob] data type because for modern RDBMSs there are at
> least 3 types of blobs; basic binary, subtype image, subtype text.
> 
> Base being a front end tool and not a database per se (ODF spec) should
> recognize the three different types and work with them appropriately.
> 
> With HSQLdb embedded for example the three blob subtypes are represented as
> Image(Blob), Memo(Text) and Other.
> 
> With the Firebird embedded they are Blob[Blob], Image[Blob] and CLOB[Blob]. 
> 
> Images[Blob] is not being properly handled by the sdbc driver as evidenced
> in the forms and reportbuilder problems.
> 
> For that matter Clob is also not handled properly by forms, and will not
> allow the report wizard to finish if the user tries to insert an Clob field
> on a form. Reportbuilder also fails to recoginize it.
> 
> Clob data types are also not being handled therefore properly by the sdbc
> code.
> 
> Also, using Blob[Blob] datatype for image data, with the 6.3 firebird sdbc
> allow images to be used and displayed in forms but does nothing to help with
> Reportbuilder. The reportbuilder code will add any Blob[Blob] field as a
> Formatted Field in the form, not an image to be displayed.

These same problems with Images and Clobs also manifest if the user tries to use them inserting data from datasources in stand alone Calc or Writer files. So the again pointing to the problem being in the sdbc driver code.
Comment 14 Robert Großkopf 2019-06-16 19:08:40 UTC
(In reply to Drew Jensen from comment #12)
> 
> For that matter Clob is also not handled properly by forms, 

The form wizard has problems with this field. If you connect a text-field to a Clob ist will work well in forms.
> and will not
> allow the report wizard to finish if the user tries to insert an Clob field
> on a form. 

The form wizard will fail here. Don't know if the report-wizard will do the same, because I have never used this wizard.

> Reportbuilder also fails to recoginize it.

He will only show a description of the field, here:
Any[Type[com.sun.star.sdbc.XClob], com.sun.star.bridges.jni_uno.JNI_proxy@1ac59125 [oid=4fa87a0;gcc3[0];502f321ca1bc4448ca08b94e14cd860, type=com.sun.star.sdbc.XClob]]

> 
> Clob data types are also not being handled therefore properly by the sdbc
> code.
> 
> Also, using Blob[Blob] datatype for image data, with the 6.3 firebird sdbc
> allow images to be used and displayed in forms but does nothing to help with
> Reportbuilder. The reportbuilder code will add any Blob[Blob] field as a
> Formatted Field in the form, not an image to be displayed.

It's a little bit confusing for me to read between the lines. You are writing of a form in Reportbuilder ... But the Report couldn't show an image of the BLOB-field with an imagecontrol. Forms could show this.
Comment 15 Drew Jensen 2019-06-16 20:57:47 UTC
Created attachment 152240 [details]
Example with 3 blob data types

Right, so my text got a little confusing.

In the example attached a table with 3 data columns, blob, image(blob), clob.

Looking just at blob and image(blob) data types.

Open Form Blobs.

This has two image controls, one attached to the blob data column, the other to the image(blob) data type. Both controls allow entering data (double click and pick an image) but only the control attached to blob data type properly reads the data. 

Open Form qryCastImage2Blob

This has two image controls, one attached to the blob data column, the other to the uses a cast function to return the image(blob) data type as a blob(blob) datatype. Both controls display the image data in the table but only the control but the data is read only. 

There is no way, that I found, to display an image from a firebird blob data type column (blob[blob] or image[blob]). 

Clob - off topic but.. can edit data using the Table View but can not be edited on a form or displayed in a reportbuilder report, displayed by dragging from the datasource window in Writer or Calc. The data can be displayed, similarly to image data by using a cast function cast( <clob> as varchar(32000)) for instance.
Comment 16 Drew Jensen 2019-06-16 21:01:01 UTC
 
This is referring only the reportbuilder:
> There is no way, that I found, to display an image from a firebird blob data
> type column (blob[blob] or image[blob]). 
>
Comment 17 Robert Großkopf 2019-08-21 17:22:55 UTC
*** Bug 127059 has been marked as a duplicate of this bug. ***
Comment 18 Julien Nabet 2019-09-15 20:06:31 UTC
Created attachment 154181 [details]
bt with debug symbols

On pc Debian x86-64 with master sources updated today, I could reproduce this.

When adding an image on a form, this one appears. Then if we save and reenter, it disappears.

Taking some time on gdb trying to understand this, it seems that at the very moment, LO "loses" the file (its stream or something).
At least, we got mnStreamLength = 0 at this precise moment (whereas obviously it was not 0 when inserting the image).
Taking a look to the bt, I noticed these lines:
#19 0x00007fffdf270d68 in dbaccess::ORowSetDataColumn::fireValueChange(connectivity::ORowSetValue const&) (this=0x55555e8a13d0, _rOldValue=...)
    at /home/julien/lo/libreoffice/dbaccess/source/core/api/CRowSetDataColumn.cxx:192
#20 0x00007fffdf326d55 in dbaccess::ORowSetBase::firePropertyChange(rtl::Reference<connectivity::ORowVector<connectivity::ORowSetValue> > const&) (this=0x55555d1187d8, _rOldRow=rtl::Reference to 0x55555cd03bc0)
    at /home/julien/lo/libreoffice/dbaccess/source/core/api/RowSetBase.cxx:1171
#21 0x00007fffdf2f6890 in dbaccess::ORowSet::updateRow() (this=0x55555d118710) at /home/julien/lo/libreoffice/dbaccess/source/core/api/RowSet.cxx:963
#22 0x00007fff23ace793 in frm::ODatabaseForm::updateRow() (this=0x55555d11ca60) at /home/julien/lo/libreoffice/forms/source/component/DatabaseForm.cxx:3442
#23 0x00007fff23c030af in frm::FormOperations::impl_commitCurrentRecord_throw(unsigned char*) const (this=0x55555e8cb520, _pRecordInserted=0x7fffffff1160 "")
    at /home/julien/lo/libreoffice/forms/source/runtime/formoperations.cxx:890
#24 0x00007fff23c02f77 in frm::FormOperations::commitCurrentRecord(unsigned char&) (this=0x55555e8cb520, _out_rRecordInserted=@0x7fffffff1160: 0 '\000')
    at /home/julien/lo/libreoffice/forms/source/runtime/formoperations.cxx:865

Just wonder if it's not again due to an update interface which is not yet implemented in Firebird part.