https://bugs.freedesktop.org/show_bug.cgi?id=56358
--- Comment #5 from [email protected] --- I use an existing postgresql backend (I've used 8.2 through 9.2 with the same results). LO connects to this backend through a jdbc driver. The data collection to populate the LO controls is done with the properties dialog for that particular control. I'm using table controls with textboxes and master/slave links in the LO form. If there is no data in the database, the table control isn't populated, which is expected behavior. But then any slave table/control that links to that unpopulated control throws an error, and no longer works, even if the parent table is later populated by moving to a new record. The link is permanently broken (until you reopen the form). For example, say you have a form like so: State Customer Orders In the State table, you have a list of all states. Click on a state, it populates the Customer table with all customers in that State. Click a customer, it shows all orders for that customer. A base form always opens with a record selected. And then the slave forms are populated based on the selected record. Say the first state is AK (Alaska) and you don't have any customers in Alaska. If the form opens with a State that has no customers, the Customer table is empty. The Orders table then attempts to populate, and since there are no Customers, it throws an error and that Orders table is broken for the rest of the session. This only happens when the form opens. If the form opens on a state with customers, then there is data in all the links, and there are no problems. You can then move to a state with no customers, and there will be no problems. But if the form opens on a state with no customers, the error is thrown and the link no longer works. The error that is thrown from the orders table would be: SELECT * FROM "public"."customer_order" WHERE ( ( "customer_id" = :link_from_customer_id ) ) AND ( 0 = 1 ) Since there is no "link_from_customer_id", the query errors out. In this case I haven't made any queries. This is all internal LO Base functionality. I assume this query is the one it created to create the Orders subform. Is that the intended behavior? To me it would seem that if the parent control wasn't populated, the slave control shouldn't attempt to populate and throw the error and break itself. This doesn't happen when using an internal HSQLDB but it happens in every instance when I'm using a PostgreSQL backend. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
