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
On which LO version are you?
4.3.5.2 on the Mac and 4.3.3.2 on Ubuntu
Thank you for your feedback, I put it back to UNCONFIRMED.
@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.
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.
@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.
@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.
(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, ...).
Created attachment 112855 [details] Simple Database to use as datasource for the main form
@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
@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 ?
(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?
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
(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.
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_
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 ?
(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
Created attachment 112953 [details] full bt
(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?
(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.
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.
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!
(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.
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.
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.
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.
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.
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.
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.
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_
(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.
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.
(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.