Bug 88814 - VIEWING: Subform linked to Mac Addressbook results in parameter count error
Summary: VIEWING: Subform linked to Mac Addressbook results in parameter count error
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.3.5.2 release
Hardware: All Mac OS X (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:4.5.0 target:4.4.1 target:4.3.7
Keywords:
Depends on:
Blocks: 89048
  Show dependency treegraph
 
Reported: 2015-01-26 19:23 UTC by Tony
Modified: 2015-02-03 16:02 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Standalone form to be connected to a name database and address book (15.33 KB, application/vnd.oasis.opendocument.text)
2015-01-26 19:23 UTC, Tony
Details
Simple Database to use as datasource for the main form (5.82 KB, application/vnd.oasis.opendocument.database)
2015-01-28 10:58 UTC, Tony
Details
full bt (41.95 KB, text/plain)
2015-01-30 13:18 UTC, Alex Thurgood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tony 2015-01-26 19:23:16 UTC
Created attachment 112815 [details]
Standalone form to be connected to a name database and address book

Hello, I have a simple standalone form with the main form attached to a ODB database with a firstname|lastname table and a subform linked to the standard address book. The two tables are connected via first and last name matches (s. attachement). The original intention was to display additional contact information stored in the address book related to a particular name. 

On a Mac using OSX Yosemite, the form doesn't work and an error pops up telling me, that the entered number of parameters does not match the number of actual parameters (SQL-Status: HY000).

The same form works without any problems using Ubuntu! 
When I switch the main and subform and its dependencies then it works on the Mac too; but that's now what I need.

Regards
Comment 1 Julien Nabet 2015-01-26 20:32:48 UTC
On which LO version are you?
Comment 2 Tony 2015-01-26 21:04:22 UTC
4.3.5.2 on the Mac and 4.3.3.2 on Ubuntu
Comment 3 Julien Nabet 2015-01-26 21:38:10 UTC
Thank you for your feedback, I put it back to UNCONFIRMED.
Comment 4 Alex Thurgood 2015-01-27 14:15:46 UTC
@Tony : in order to test this, we would need a test ODB file, else we could end up trying to reproduce a database file that bears no correlation to what you have.

What do you mean by "subform linked to standard address book".


What I will note is that if I right mouse button click in the first grid control on one of the headers, I get a fatal crash, it seems LO can not handle gracefully missing path objects, i.e. the referenced ODB. Will open a separate report for this.


Setting to needinfo until requested information is provided. Once you have provided the requested information, please set back to unconfirmed.
Comment 5 Tony 2015-01-27 16:59:28 UTC
I will have to create an anonymized version of the name database. However, you should be able to reproduce it with a simple ODB database consisting of a single table named contacts, whith a field for firstname and a second one for lastname. 
In the standalone form you then have to select that database and its contact table as data source

LibreOffice gives you the possibility to "register an address book". This feature creates a read-only address database which allows you to access values of your external address book. On the Mac I use the OSX Contacts.

Now you have to select this address book as data source for your subform and make sure your fields for firtsname and lastname match.
Comment 6 Alex Thurgood 2015-01-27 17:42:19 UTC
@Tony : You still don't explain how you bind your subform linking to a first datasource (OSX read-only addressbook ODB) to a different datasource (the fname/lname ODB)in your main form.

Additionally, how were you read able to read your Mac OSX Addressbook on Ubuntu, since you mention that it worked there ? My understanding of the OSX addressbook format was that it wasn't readable on other OSes.
Comment 7 Tony 2015-01-27 19:10:54 UTC
@Alex:

Sorry, I was under the impression, that the linking can be seen in the attached form. All dtabase connections and subform/mainform links are done in design mode using the form navigator and the form properties/data dialogs. 

1. The main form is connected to the ODB name database by selecting the filename of the database and then the corresponding table.
2. To connect the subform to the previously registered address book I select it as data source in the drop down list of the subform property/data tab.

On Ubuntu I have to use another address book of course. I chose the Thunderbird one. My aim is to get it working on the Mac; I only used Ubuntu for test purpose to narrow down the error.
Comment 8 Lionel Elie Mamane 2015-01-27 22:51:53 UTC
(In reply to Tony from comment #7)

> On Ubuntu I have to use another address book of course. I chose the
> Thunderbird one. My aim is to get it working on the Mac; I only used Ubuntu
> for test purpose to narrow down the error.

Could you please test with the Thunderbird address book on Mac? This will allow us to see if the bug is specific to the Mac Address book driver, or if it in some other Mac-specific part.


(In reply to Tony from comment #5)
> I will have to create an anonymized version of the name database. However,
> you should be able to reproduce it with a simple ODB database consisting of
> a single table named contacts, whith a field for firstname and a second one
> for lastname. 

If one "should" be able to reproduce it in this way, then please do reproduce it in this way, and attach the reproduction examples (the .odb file, a dump of the address book used to test, ...).
Comment 9 Tony 2015-01-28 10:58:50 UTC
Created attachment 112855 [details]
Simple Database to use as datasource for the main form
Comment 10 Tony 2015-01-28 11:04:38 UTC
@Lionel,
I've attached the sample database to be used for reproducing the error. As I do not use Thunderbird on the Mac, I will see what I can do, but that certainly will take some time

Thank you
Comment 11 Alex Thurgood 2015-01-28 17:49:11 UTC
@Tony : well, making an ODB from a Mac OSX addressbook is certainly possible (or at least it was, unless a new bug has been introduced), however I'm absolutely uncertain how two different drivers are supposed to be able to bind two different datasources together in the same form/subform document and have their records synchronized - sounds like dark magic to me ?
Comment 12 Lionel Elie Mamane 2015-01-28 18:05:16 UTC
(In reply to Alex Thurgood from comment #11)
> @Tony : well, making an ODB from a Mac OSX addressbook is certainly possible
> (or at least it was, unless a new bug has been introduced), however I'm
> absolutely uncertain how two different drivers are supposed to be able to
> bind two different datasources together in the same form/subform document
> and have their records synchronized - sounds like dark magic to me ?

It is possible in forms in a writer document: each form has a property "which datasource should I bind to".

It is not possible in a Base form document, but (in my judgement) there is no deep technical reason for that, just that nobody has worked on the easyhack/enhancement bug I filed for it :) I expect it wouldn't take much work to unlock that possibility, since the code already supports it!

Open the "Standalone form to be connected to a name database and address book" attachment, go into form design mode, open the form navigator and look at the properties of each form.


Since you have a Mac, maybe you could check if this is specific to the MacAB (Mac Address Book) driver or if it happens with some other address book driver, too?
Comment 13 Tony 2015-01-29 06:33:52 UTC
I've installed Thunderbird on the Mac and made the test with its address book. Guess what - the form works with the Thunderbird address book attached.

Hence the error is likely to be in the LibreOffice connection to the OSX address book. This has the version 9.0 (contacts) and runs under Yosemite 10.10.1.


If you need more information, please let me know
Comment 14 Alex Thurgood 2015-01-30 10:39:28 UTC
(In reply to Lionel Elie Mamane from comment #12)


> 
> Since you have a Mac, maybe you could check if this is specific to the MacAB
> (Mac Address Book) driver or if it happens with some other address book
> driver, too?

Will take a look and see what I can / can't do with this on OSX.
Comment 15 Alex Thurgood 2015-01-30 11:32:46 UTC
Finally managed to reproduce the reported error, and can confirm the message :

SQL Status: HY000

The count of the given parameter values doesn't match the parameters.



on 
Version: 4.5.0.0.alpha0+
Build ID: c106f83da16726506962e19bcbc3d4c25415b81a
Locale: fr_
Comment 16 Alex Thurgood 2015-01-30 11:34:11 UTC
Surely this is because the subfrom references 3 data fields in the grid control, whereas the links between the two data sources only reference 2 fields ?
Comment 17 Alex Thurgood 2015-01-30 11:48:05 UTC
(lldb) c
Process 14398 resuming
warn:xmloff.core:14398:1:xmloff/source/core/xmlimp.cxx:932: exception caught
warn:legacy.osl:14398:1:xmloff/source/core/xmlimp.cxx:933: caught an exception!
in function:virtual void SvXMLImport::setTargetDocument(const uno::Reference<lang::XComponent> &)
type: com.sun.star.lang.NotInitializedException
context: N8dbaccess17ODatabaseDocumentE

warn:xmloff.core:14398:1:xmloff/source/core/xmlimp.cxx:932: exception caught
warn:legacy.osl:14398:1:xmloff/source/core/xmlimp.cxx:933: caught an exception!
in function:virtual void SvXMLImport::setTargetDocument(const uno::Reference<lang::XComponent> &)
type: com.sun.star.lang.NotInitializedException
context: N8dbaccess17ODatabaseDocumentE

warn:xmloff.core:14398:1:xmloff/source/core/xmlimp.cxx:932: exception caught
warn:legacy.osl:14398:1:xmloff/source/core/xmlimp.cxx:933: caught an exception!
in function:virtual void SvXMLImport::setTargetDocument(const uno::Reference<lang::XComponent> &)
type: com.sun.star.lang.NotInitializedException
context: N8dbaccess17ODatabaseDocumentE

warn:legacy.osl:14398:1:dbaccess/source/core/api/SingleSelectQueryComposer.cxx:846: OSingleSelectQueryComposer::getColumns: inconsistent column counts, this might result in wrong columns!
warn:legacy.osl:14398:1:dbaccess/source/core/api/SingleSelectQueryComposer.cxx:846: OSingleSelectQueryComposer::getColumns: inconsistent column counts, this might result in wrong columns!
warn:legacy.osl:14398:1:comphelper/source/misc/types.cxx:85: OSL_ASSERT: 0
warn:legacy.osl:14398:1:comphelper/source/misc/types.cxx:85: OSL_ASSERT: 0
Comment 18 Alex Thurgood 2015-01-30 13:18:38 UTC
Created attachment 112953 [details]
full bt
Comment 19 Tony 2015-01-30 21:31:32 UTC
(In reply to Alex Thurgood from comment #16)
> Surely this is because the subfrom references 3 data fields in the grid
> control, whereas the links between the two data sources only reference 2
> fields ?

If you would only be allowed to use fields, which are used for selection, what would be the added value of the subform? The idea of a subform linked to fields in a master form is to show additional information related to the selection.

And why should it be possible using the Thunderbird address book but not the Mac Contacts?
Comment 20 Alex Thurgood 2015-01-31 14:24:04 UTC
(In reply to Tony from comment #19)


> And why should it be possible using the Thunderbird address book but not the
> Mac Contacts?

I have no idea. At a guess, the drivers must behave differently - whether by design or by error.
Comment 21 Commit Notification 2015-01-31 16:03:28 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d2a6d6a1a05337dbb733a9a3d4926a5c6d6cd8cd

tdf#88814 parameters are kinda-partially supported, so follow the suggestion

It will be available in 4.5.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 22 Lionel Elie Mamane 2015-01-31 16:04:54 UTC
This *may* be fixed by the commit I just made:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d2a6d6a1a05337dbb733a9a3d4926a5c6d6cd8cd

Someone please test a recent-enough master build, and if it works I'll backport to 4.4 and 4.3.

Thanks in advance!
Comment 23 Alex Thurgood 2015-01-31 17:08:04 UTC
(In reply to Lionel Elie Mamane from comment #22)

 
> Someone please test a recent-enough master build, and if it works I'll
> backport to 4.4 and 4.3.
> 


Will start a new build tonight and test tomorrow.
Comment 24 Commit Notification 2015-02-02 14:46:41 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-4-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=291aa47b6039acb80472769362ce6dca14bd98cb&h=libreoffice-4-4

tdf#88814 parameters are kinda-partially supported, so follow the suggestion

It will be available in 4.4.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 25 Alex Thurgood 2015-02-02 14:50:50 UTC
Not sure whether due to change above, but the form has become approx 30 times slower to load - so much so that OSX app scheduler thinks that app has stopped responding.

When the test form finally does open, no error message is displayed, but then neither is any data shown in the lower grid control, i.e. nothing is bound.

Attempting to cycle through the records in upper form with the down arrow of the keyboard causes LO to SIGBART when it reaches the new record line of the grid.
Comment 26 Lionel Elie Mamane 2015-02-02 14:55:09 UTC
With the kind help of a co-developer here at the hackfest, I could test on a Mac. After applying my patch, and after correcting the field names to what they are in the addressboox on the Mac we were testing on, it works. Closing the bug.


Tony, I recommend that you use the "UID" field rather than "First" and "Last" (name) as master/slave fields.
Comment 27 Alex Thurgood 2015-02-02 14:58:02 UTC
An example of the slowness involved :
Load TestAdressen.odt
Switch to form design mode
Click on upper grid control, right mouse button click, choose Form, and select Data tab.
Then click on the ellipsis to choose the datasource.
It takes LO a full minute to open the Finder dialog.
Comment 28 Commit Notification 2015-02-02 15:10:25 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-4-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=81d5fd2d6556c65f1690876cc247568e2288897e&h=libreoffice-4-3

tdf#88814 parameters are kinda-partially supported, so follow the suggestion

It will be available in 4.3.7.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 29 Alex Thurgood 2015-02-02 15:18:15 UTC
Confirming that I finally got it to work too with commit.

I had to change the lower grid control completely. Deleted and inserted a new one pointing to MacAddressbook.odb registered database.

Altered data in TestAdressen.dob to correspond to the records in MacAb, and then it worked.
Comment 30 Alex Thurgood 2015-02-02 15:35:12 UTC
Performance is terrible on first opening of the form.

From the StartCenter, clicking on the preview of the form document to complete loading of the form takes 1 min 22s with 

Version: 4.5.0.0.alpha0+
Build ID: bfceafa67ed1cc3e4e03f8f214a2716f57b2d1e7
Locale: fr_
Comment 31 Tony 2015-02-02 16:03:21 UTC
(In reply to Lionel Elie Mamane from comment #26)
> With the kind help of a co-developer here at the hackfest, I could test on a
> Mac. After applying my patch, and after correcting the field names to what
> they are in the addressboox on the Mac we were testing on, it works. Closing
> the bug.
> 
> 
> Tony, I recommend that you use the "UID" field rather than "First" and
> "Last" (name) as master/slave fields.

Lionel,

That would be the correct joice when starting with a new relational database, but unfortunatley there is no UID relation between the two existing ones and I alreay have hundreds of contacts, which were inherited from other sources. It would probably need some programming to get the existing UID field replaced with the MacAdressbook key or create a mapping table.
Comment 32 Lionel Elie Mamane 2015-02-03 15:24:30 UTC
The slowness is the tccd process taking its sweet time, pumping CPU time. A web search suggests this is a problem common to all / many applications trying to access the address book, and a problem in MacOS X.
Comment 33 Alex Thurgood 2015-02-03 16:02:32 UTC
(In reply to Lionel Elie Mamane from comment #32)
> The slowness is the tccd process taking its sweet time, pumping CPU time. A
> web search suggests this is a problem common to all / many applications
> trying to access the address book, and a problem in MacOS X.

What can I say, nice one Apple ! One more reason to use TB addressbook instead.