Created attachment 106837 [details]
Displayed with 4.2.6.3

Created attachment 106838 [details]
Displayed with 4.3.2.2

As reported to me this was working as expected in 4.3.1.2 as well.

UNCONFIRMED->NEW: was confirmed by an independent party.

Severity Critical unless this is a 4.3.0->4.3.2 regression.

I reported this to Rico this morning, assuming it was a new ubuntu release problem.  I was previously running 4.3.1.2 from the ubuntu ppa.


I was also running 4.3.2 development version direct from libreoffice to test another issue, version:  

Version: 4.3.2.0.0+ Build ID: b2d54aa61607e477cb4b81f1a70e555ee3adb0af
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-4-3, Time:
2014-08-20_23:12:37

This was OK, which is why I assumed it was an ubuntu release problem.



I am a little concerned.  If this applies on all platforms, then no databases at all will work with 4.3.2.2, with all that implies.

I have done a little more investigation.

First, on the libreoffice website 4.3.2.2 still seems to be a pre-release, so I am a little surprised it was release to the ubuntu normal release ppa.

Secondly, on Windows 64 bit I downloaded 4.3.2.2 from the LO website and it is OK.

Thirdly, I thought I should download the linux deb 4.3.2.2 from the libreoffice website.  I did, and it works.

So after a very brief series of tests this appears to be an ubuntu release problem, not a libreoffice problem.  Please forgive me if I've made an error in my checking somewhere, but this issue seemed so serious for database users that I thought I should progress it as fast as possible.

(In reply to comment #7)
> First, on the libreoffice website 4.3.2.2 still seems to be a pre-release,
> so I am a little surprised it was release to the ubuntu normal release ppa.

"This PPA might contain the release candidate that is assumed to become the final release even before it is declared so by the Document Foundation (e.g. usually release candidate 2 for minor updates)."
https://launchpad.net/~libreoffice/+archive/ubuntu/ppa

So nothing surprising there at all, if you read the PPA description.

> Secondly, on Windows 64 bit I downloaded 4.3.2.2 from the LO website and it
> is OK.
> 
> Thirdly, I thought I should download the linux deb 4.3.2.2 from the
> libreoffice website.  I did, and it works.

This is certainly interesting. Normally I would close the bug as NOTOURBUG here then (because it would be a distro bug only). I have an idea about the reason though, as I enabled mergedlibs on 4.3.2 and had to move some lib into it to get rid of circular deps: dbtools -- which sounds like it could cause this trouble.
 
Adding distro bug reference.

Björn,

So much to read, so little time :-)   Apologies - I should have re-read all of the PPA description.  My mistake.

Tim

Ah, in 8165fc23014c8044c131cb6e1fd0c5e06fd0da2d I've added dbtools to libmerged just to fix circular dependency without checking it's OK.

git grep '"dbtools"' finds
svx/source/form/dbtoolsclient.cxx
sw/source/uibase/dbui/swdbtoolsclient.cxx
there might be more but hopefully this is all.

One option is fix similar to 'git grep CUI_DLL_NAME vcl/'

But in this case, since svxcore already links against dbtools, we either want to link also sw properly and fix those files.

Or, get dbtools out of libmerged and create some hack for whatever was the reason to link against dbtools in 86bdb13704d9d85a247339071a86d301ce86cd7f "fdo#67615 TextField in table should use same formatting as floating TextField"

I don't know what's in dbtools library. I would think it's not core functionality to be really needed and used in libmerged (svxcore) but maybe it is? It's also not the smallest one, 2.2MB

This also could be an easy hack.

NO REPRO with (TDF-built) LO 4.3.2.2 + Ubuntu 14.04

(In reply to comment #0)
> Example hsqldb database
> 
> Numeric are not correctly display and either an empty field or "0" is shown.

Repro Steps:

1) Open test.odb
2) Database -> Tables -> (double click on) test-table
3) See that the numeric values are empty/0 as described by OP

Here's what I see:

id  name  count
0   foo   42
1   bar   4711

(In reply to comment #8)
> This is certainly interesting. Normally I would close the bug as NOTOURBUG
> here then (because it would be a distro bug only).

Agreed.

> I have an idea about the
> reason though, as I enabled mergedlibs on 4.3.2 and had to move some lib
> into it to get rid of circular deps: dbtools -- which sounds like it could
> cause this trouble.
>  
> Adding distro bug reference.

Okay, leaving this one for you, Bjoern. Feel free to assign it to yourself, given that it's not something we can repro with current TDF builds.

*** Bug 84332 has been marked as a duplicate of this bug. ***

(In reply to comment #10)
> Ah, in 8165fc23014c8044c131cb6e1fd0c5e06fd0da2d I've added dbtools to
> libmerged just to fix circular dependency without checking it's OK.

> Or, get dbtools out of libmerged and create some hack for whatever was the
> reason to link against dbtools in 86bdb13704d9d85a247339071a86d301ce86cd7f
> "fdo#67615 TextField in table should use same formatting as floating
> TextField"

The reason what that LibreOffice contains two implementations of the same "feature", namely in a database context to format a value. I ripped out the use of one (svxform::OTypeConversionClient, which was buggy in the way described in bug 67615) in the favour of the other (dbtools::FormattedColumnValue).

> I don't know what's in dbtools library.

Utilities and base classes that are useful in a database context.

> I would think it's not core functionality

What is "core functionality" and what is not "core functionality" in LibreOffice? Do we have a clear policy about that?

> to be really needed and used in libmerged (svxcore) but maybe
> it is?

Well, parts of svxcore *do* deal with database stuff, so *if* svxcore is to be considered as completely "core functionality", then dealing with database stuff is "core functionality". If this contradicts in some way the yet-unknown-to-me policy about "core functionality", and *parts* of svxcore need to be considered "core feature" then maybe we can/should rip out the non-core parts of svxcore out of svxcore and place them into another library?

More hackishly, there is some infrastructure in place (namely connectivity::ODataAccessStaticTools) to handle this kind of things as a "dlopen at runtime instead of build-time link". We could extend that, but I'd much rather we solved the root cause rather than extending a band-aid (which I'd rather see destroyed).

My meaning was "if svxcore deals with database stuff, it is normal it uses a database stuff utility functions library".

Another approach would be to tailor what's in dbtools. Maybe we can move stuff from it to another library if it helps?

Just confirming quickly: I reproduce this bug with --enable-mergedlibs and it goes away without mergedlibs. Reducing severity to normal as --enable-mergedlibs is currently not used for upstream builds.

I see the severity has been reduced.  

Now I don't understand these things, so forgive me for asking.  However, why is this less severe now, since the current ubuntu ppa release for BASE users is still unusable?

(In reply to comment #16)
> I see the severity has been reduced.  
> 
> Now I don't understand these things, so forgive me for asking.  However, why
> is this less severe now, since the current ubuntu ppa release for BASE users
> is still unusable?

This bug tracker tracks the severity of bug for the upstream LibreOffice project. Ubuntu-only packaging bugs are tracked on Launchpad. Note that even there a ppa-only issue isnt as critical as one in the main distro repository. Running the latest and greatest always has its tradeoff.

Also: Please direct further general bugtracking questions to the QA-list at http://nabble.documentfoundation.org/QA-f3613148.html or http://www.libreoffice.org/community/qa/. Please keep the bug tracker only for comments directly relevant to the specific issue at hand. Thanks.

(In reply to comment #17)
> (In reply to comment #16)
> > I see the severity has been reduced.  
> > 
> > Now I don't understand these things, so forgive me for asking.  However, why
> > is this less severe now, since the current ubuntu ppa release for BASE users
> > is still unusable?
> 
> This bug tracker tracks the severity of bug for the upstream LibreOffice
> project. Ubuntu-only packaging bugs are tracked on Launchpad. Note that even
> there a ppa-only issue isnt as critical as one in the main distro
> repository. Running the latest and greatest always has its tradeoff.
> 
> Also: Please direct further general bugtracking questions to the QA-list at
> http://nabble.documentfoundation.org/QA-f3613148.html or
> http://www.libreoffice.org/community/qa/. Please keep the bug tracker only
> for comments directly relevant to the specific issue at hand. Thanks.
OK, thanks.  I'll await information on launchpad #1373928.

(In reply to comment #14)
> Another approach would be to tailor what's in dbtools. Maybe we can move
> stuff from it to another library if it helps?

Ah, no, it's fine.
Sorry, I should not ask that much.
I am not really against dbtools in libmerged, it surely has its reasons.
Main reason I've added you to cc was, just so that you know about this bug - which probably was not necessary :-)

Thanks for explanations!

I have downloaded and tested the most recent ubuntu build - 1:4.3.2~rc2-0ubuntu1~trusty2 - and the problem is fixed.

Thanks to all.

I have not changed the status of this report since I'm not sure if a final decision has been made on the correct set of libraries to be used.

I have also updated the launchpad report #1373928.

Worth checking for symbol conflicts between dbaccess and mergedlibs I guess; I did a quick:

objdump -T instdir/program/libdbtoolslo.so   | c++filt | grep -v '\*UND\*' | grep -v '    connectivity::' | grep -v '    dbtools::' | grep -v 'non-virtual thunk to connectivity::' | grep -v 'non-virtual thunk to dbtools::' | grep -v '  vtable ' | grep -v '   typeinfo ' | less

And I spotted:

createDataAccessToolsFactory

which looks unusual to me.

I suggest someone with a bit of a clue - go on Bjoern you know you want to does:

git grep -10 createDataAccessToolsFactory

and applies the obvious fixup =)

(In reply to comment #21)
> Worth checking for symbol conflicts between dbaccess and mergedlibs I guess;

> And I spotted:
 
> createDataAccessToolsFactory
 
> which looks unusual to me.

OTOH, it seems to be defined only there, and only used / declared in other places.

My guess is more in the direction that now dbtools is both linked *and* dlopen()ed from libsvxcore (and thus mergedlibs), and when dbtools is in mergedlibs, the svxcore code does not find libdbtoolslo.so/dylib/dll to dlopen(). So we should change the dlopen() mechanism in the mergedlibs case to not try to do dlopen() and just assume the symbols are there? Something like that.

Is there an "#ifdef" we can do to detect mergedlibs case?

Sorry, I was probably not clear enough in my first comment. :-/

(In reply to comment #22)
> So we should change the dlopen() mechanism in the mergedlibs case

Ideally we would just kill this dlopen.

> Is there an "#ifdef" we can do to detect mergedlibs case?

I guess it was removed because it's not necessary..
git grep CUI_DLL_NAME vcl/ shows

-DCUI_DLL_NAME=\"$(call gb_Library_get_runtime_filename,$(call gb_Library__get_name,cui))\" \

in makefile, and you can then use in source CUI_DLL_NAME instead of just "cui" without any #ifdefs
It expands to the exact platform specific name, so no need for SVLIBRARY then.

But really, we should kill that ugly createDataAccessToolsFactory mess and benefit. :-)

(In reply to comment #23)
> Sorry, I was probably not clear enough in my first comment. :-/
> 
> (In reply to comment #22)
> > So we should change the dlopen() mechanism in the mergedlibs case
> 
> Ideally we would just kill this dlopen.

That's a good plan for master, and WiP is at https://gerrit.libreoffice.org/11737

*But* I wouldn't do that in the stable branch... Additionally to timing issues (that is, when will the full "kill the dlopen()" be done?), it is a rather bigger change, and instead of making many changes everywhere, I'd rather the dlopen mechanism (that is, the whole svx/dbtoolsclient) just didn't do the dlopen(); that's *one* change in *one* place, "neutering" the mechanism instead of killing it (that is, essentally making it a no-op instead of changing every place that calls it to not call it).

>> Is there an "#ifdef" we can do to detect mergedlibs case?

> git grep CUI_DLL_NAME vcl/ shows

> -DCUI_DLL_NAME=\"$(call gb_Library_get_runtime_filename,$(call
> gb_Library__get_name,cui))\" \

> in makefile, and you can then use in source CUI_DLL_NAME instead of just
> "cui" without any #ifdefs
> It expands to the exact platform specific name, so no need for SVLIBRARY
> then.

You mean "$(call gb_Library__get_name,cui)" will expand to "mergedlib" (or something like that) in the --enable-mergedlib case?

(In reply to comment #24)
> You mean "$(call gb_Library__get_name,cui)" will expand to "mergedlib" (or
> something like that) in the --enable-mergedlib case?

Sure, (e.g. to libmergedlo.so) and to libcuilo.so in --disable-mergelibs case.

I encountered this bug on my opensuse 13.1 system with LO 4.3.2.2 from factory-repo/OBS.
Therefore it is not only ubuntu and might be an upstream issue.

BTW if I create a simple form within the example database, it will not show any data at all.

On an another similar machine the table view of a mysql database showed all text values wrong as "0" (the other way round!) when the form displayed only text fields correctly...

LO 4.3.1.2 as it comes with opensuse 13.2 RC1 works properly here.

   Yesterday, I downloaded LibreOffice from the PPA to test this problem on a 32 bit laptop using Ubuntu 14.04. (Mine was associated with the possibility of the mysql native connector might be the cause of this problem when using MySQL with LibreOffice. (Stefan Gruber and I have been on the LibreOffice user mailing list about it.)
   Today he gave me a link to this bug. So this evening, I have down the example database and opened it using LibreOffice from the PPA. I saw the following results:

0   foo   42
1   bar   4711

LibreOffice information: 
Version: 4.3.2.2
Build ID: 430m0(Build: 2)

     Have they fixed the problem with a newer version of the download file?

(In reply to Dan Lewis from comment #27)
>    Yesterday, I downloaded LibreOffice from the PPA to test this problem on
> a 32 bit laptop using Ubuntu 14.04. (Mine was associated with the
> possibility of the mysql native connector might be the cause of this problem
> when using MySQL with LibreOffice. (Stefan Gruber and I have been on the
> LibreOffice user mailing list about it.)
>    Today he gave me a link to this bug. So this evening, I have down the
> example database and opened it using LibreOffice from the PPA. I saw the
> following results:
> 
> 0   foo   42
> 1   bar   4711
> 
> LibreOffice information: 
> Version: 4.3.2.2
> Build ID: 430m0(Build: 2)
> 
>      Have they fixed the problem with a newer version of the download file?
That display looks correct to me.

(In reply to Dan Lewis from comment #27)
>      Have they fixed the problem with a newer version of the download file?


https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1373928/comments/23

This bug shall remain open though until this works again with --mergedlibs

*** Bug 86036 has been marked as a duplicate of this bug. ***

I increase the importance of this since even if it's not a crash:
- it's a regression
- it's not a corner case
- there's no clear error or warning messages on UI to indicate there's a problem

Matus/Lionel: any advance on this one?

Seems that LO 4.3.3.2 displays values correctly again.
Tested with opensuse factory build.

Adding Whiteboard:notBibisectable as this bug appears to depend on specific compile options

Adding self to CC if not already on

resolved as per comment 32.

Migrating Whiteboard tags to Keywords: (notBibisectable)
[NinjaEdit]