I am struggling to get my head around a problem I am getting with records being saved. I am finding that my record with a calculation is not being saved to the database and when I run a debug session I can see that there is an unsaved record (using databaseManager.getEditedRecords()) but nothing I do seems to be able to get this record saved to the database. Below is a transcript from the Interactive console which shows there is 1 edited record which is for the table case_stage. If I then issues a databaseManager.saveData() the return value is false which indicates an error has occurred and running databaseManager.getEditedRecords().length shows there is still 1 edited record. A further attempt to save the record is also false but if I run databaseManager.getFailedRecords() it returns nothing!!!
Nothing out of the ordinary showing in the PostgreSQL log at all. I am running PostgreSQL 9.4 and Servoy 7.4.4 on OS X Yosemite and it is driving me nuts. I’m also having a related issue with calculations on these same records which may or may not be causing the problem. I have three tables related as follows:
case_stage ← one to many → case_report ← one to many → case_report_expert
case_report_expert has cancelled_on and completed_on fields.
case_report has stored calculations cancelled_on and completed_on that are based on the related case_report_expert records
case_stage has stored calculations cancelled_on and completed_on that are based on the related case_report records
If I make a change to a case_report_expert record the calculations are correctly updated for the case_report record but not for the case_stage and I can’t figure out why and this appears to be related to the error I’m getting above.
After a lot of debugging work I can see the following happening and am wondering if this is normal:
Start a transaction
Update the child record (this will affect the calculations in both the parent and grandparent record)
Save the child record (databaseManager.saveData(childRecord)
Save the parent record (databaseManager.saveData(parentRecord)
Save the grandparent record (databaseManager.saveData(grandparentRecord)
Commit the transaction
At the end of this I would expect everything to be saved and up to date but if I set a breakpoint immediately after the transaction has been committed and issue a databaseManager.getEditedRecords() I can see the the parent record is showing as having changes and getRecordChanges() shows it is the calculation that has been changed.
For now the only solution I have been able to find is to manually do a databaseManager.recalculate() on the parent and grandparent records immediately before the databaseManager.saveData() and this then leaves all the records clean when the transaction completes.
I’d love to know why the calculation is triggered only AFTER the transaction has been committed.
I have had endless fun with calculations on older versions of Servoy. In the end I solved the problems by removing the troublesome calculations and updating the fields manually during table events.
One thing to watch out for is running manual SQL queries during updates of data structures – the data may not be saved yet so the database does not see it.
PostgreSQL 9.4 and Servoy 7.4.4 on OS X Yosemite is not causing me any particular problems. The stack seems pretty stable at the moment.
I wouldn’t exactly call it fun but it is certainly endless!! The one I have totally given up on is aggregations - I cannot get these to work at all. I have a foundset with a single record and a MAX() aggregation on a date field which has a valid date and the aggregation value is null!
I’ll stick with the explicit recalculate call for now and see what happens
I don’t know the code of your calculation, but from what you’re writing I get the understanding that you use relations within the calculation.
As Christian already mentioned: endless fun.
The best advise is: stop using them.
Calculations are only useful when you calculate within a table (ie. concatenating text fields, create subtotals, etc.)
Otherwise it will dramatically slow down your solution in the end.
Using relations in calculations to aggregate is just fine. I have hundreds of them in tables with 500k records. No issue at all. But yes, using relations in a calculation and looping over the relation is very bad…