Description: Upgraded from version 6.1.5.2 to 6.2.3.2 and now when I open any existing form I get "The SQL command leading to this error is: SELECT * FROM "fc"."transactions" WHERE ( "fc"."transactions"."t_bank_id" = :link_from_a_bank_id )". Steps to Reproduce: 1.A simple Form created of bank account master record filtered for one particular bank_id and transactions linked by bank_id. 2.A list box for all the transactions. 3. Actual Results: The SQL command leading to this error is: SELECT * FROM "fc"."transactions" WHERE ( "fc"."transactions"."t_bank_id" = :link_from_a_bank_id ) Expected Results: list box should show all transactions for the bank account. Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-GB Module: FormDesign [Information guessed from browser] OS: Windows (All) OS is 64bit: no
Created attachment 151404 [details] Screen shot of Form
Here is the sql to create the table structure as used in the Form. -- -- Table structure for table `bank_account` -- DROP TABLE IF EXISTS `bank_account`; /*!40101 SET @saved_cs_client = @@character_set_client */; /*!40101 SET character_set_client = utf8 */; CREATE TABLE `bank_account` ( `a_bank_id` int(10) NOT NULL AUTO_INCREMENT, `a_bank_account` varchar(50) DEFAULT NULL, `a_bank` varchar(100) DEFAULT NULL, `a_tax_rate` double(16,2) DEFAULT NULL, `a_interest_rate` double(16,4) DEFAULT NULL, `a_interest_rounding` int(10) NOT NULL, `a_interest_truncate` int(10) NOT NULL, `a_tax_truncate` int(10) NOT NULL, `a_amount_rounding` int(10) NOT NULL, `a_amount_truncate` int(10) NOT NULL, `a_basis_divisor` double(16,2) DEFAULT NULL, `a_long_short_term` char(1) NOT NULL, `a_country` varchar(10) DEFAULT NULL, `a_closed` varchar(1) NOT NULL, PRIMARY KEY (`a_bank_id`) ) ENGINE=InnoDB AUTO_INCREMENT=48 DEFAULT CHARSET=utf8; /*!40101 SET character_set_client = @saved_cs_client */; DROP TABLE IF EXISTS `transactions`; /*!40101 SET @saved_cs_client = @@character_set_client */; /*!40101 SET character_set_client = utf8 */; CREATE TABLE `transactions` ( `t_bank_id` int(7) NOT NULL, `t_date` date NOT NULL, `t_amount` decimal(16,2) NOT NULL, `t_comment` varchar(100) DEFAULT NULL, `t_interest_rate` double(16,4) NOT NULL, `t_tran_type` char(1) NOT NULL, `t_id` int(10) NOT NULL AUTO_INCREMENT, PRIMARY KEY (`t_id`), UNIQUE KEY `index1` (`t_bank_id`,`t_date`,`t_id`) ) ENGINE=InnoDB AUTO_INCREMENT=25425 DEFAULT CHARSET=utf8; /*!40101 SET character_set_client = @saved_cs_client */; -- -- Temporary view structure for view `v_bank_account` -- DROP TABLE IF EXISTS `v_bank_account`; /*!50001 DROP VIEW IF EXISTS `v_bank_account`*/; SET @saved_cs_client = @@character_set_client; SET character_set_client = utf8; /*!50001 CREATE VIEW `v_bank_account` AS SELECT 1 AS `a_bank_id`, 1 AS `a_bank_account`, 1 AS `a_bank`, 1 AS `a_tax_rate`, 1 AS `a_interest_rate`, 1 AS `a_interest_rounding`, 1 AS `a_interest_truncate`, 1 AS `a_tax_truncate`, 1 AS `a_amount_rounding`, 1 AS `a_amount_truncate`, 1 AS `a_basis_divisor`, 1 AS `a_long_short_term`, 1 AS `a_country`, 1 AS `b_date`, 1 AS `b_balance`*/; SET character_set_client = @saved_cs_client;
It's due to a side effect of a fix. You can use macro described there for impacted files: https://bugs.documentfoundation.org/show_bug.cgi?id=117053#c15 Waiting for your feedback about this.
(In reply to Julien Nabet from comment #3) > It's due to a side effect of a fix. > You can use macro described there for impacted files: > https://bugs.documentfoundation.org/show_bug.cgi?id=117053#c15 > > Waiting for your feedback about this. Yes changing that one parameter has fixed it. A bit of a hassle doing it though. Hasn't anybody with more scripting skills than I have written a script to make to change to all .odb files? Thanks Rob.
Thank you for your feedback, let's put this one to WFM since nothing has been changed in LO code for this. About your question, I don't know. How many files do you have?
(In reply to Julien Nabet from comment #5) > Thank you for your feedback, let's put this one to WFM since nothing has > been changed in LO code for this. > > About your question, I don't know. How many files do you have? Don't worry about me I have patched all of my own .odb files and made a note in case I need to fix it again. Thanks Rob.
Ok then but please don't put back again FIXED since there's no patch about this, you just used macro from a comment.
(In reply to Julien Nabet from comment #7) > Ok then but please don't put back again FIXED since there's no patch about > this, you just used macro from a comment. You are right, the problems are not fixed. I had not discovered that after the patch I am unable to edit the contents of tables. eg. When you double click on any table in the tables window the form which opens used to allow me to edit the contents of the table. Now it appears as if it is read-only. I have tried with the pre-patched version of the .odb and it is the same, ie. not allowing editing.
I'm not sure to understand. Do you mean once you applied the macro quoted in a previous comment, your tables are now in read-only?
(In reply to Julien Nabet from comment #9) > I'm not sure to understand. > Do you mean once you applied the macro quoted in a previous comment, your > tables are now in read-only? No, forget about the macro. This is even before making any changes to the odb files. It appears after the upgrade that I cannot edit any table data. The forms etc are not showing read-only in the title bar but just that the editing icons like 'plus' to add a record are greyed out. I have checked with the mysql server that the user still has update rights and it does. Nothing else has changed, just the upgrade from version 6.1.5.2 to 6.2.3.2.
Ok, then it's another bug. Please open a new bugtracker and let's close this one.