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.
@Drew : is this not a DUP of bug 117435 ?
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."
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.
(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.
(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
Created attachment 147310 [details] Symbols backtrace for crash when attempting to open report
(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.
(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 ;)
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?
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
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.
(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.
(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.
(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.
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.
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]). >
*** Bug 127059 has been marked as a duplicate of this bug. ***
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.
I gave a try with: https://gerrit.libreoffice.org/c/core/+/105899 For first attachment "Example db", the image (at left) displays, nothing at right side. For third attachment "Example with 3 blob data types", both images display now instead of one.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/61560ae7d6f00ba6b410f7779e9a46cf692a5400 tdf#121886: Firebird Datatype Image(BLOB) is not working properly It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5c6340d06b4e58529f6122ecf3b26c6d4456226b Related tdf#121886: Firebird Datatype Image(BLOB) is not working properly It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/537e0fabf1cec7ea74a9d2fb93b795b902588e24 tdf#121886: Firebird Datatype Image(BLOB) is not working properly It will be available in 7.0.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.