We are carrying out of the tests for the migration to Servoy 3.1.6.
In some solution, When create a new record with instruction “controller.newRecord()”, the record do not exist in database until the instruction “controller.save()” is executed.
In Servoy 2.2.7 don’t exist this, the record was created succesfully.
This is a problem for us when we migrate our solutions in Servoy 3.1.6 because cause the review of all the solutions!
After instruction controller.newRecord(), the method defined various fields (but the record does not created in the DB) and after, it tries to create also of the records correlated but not existing the master record and it gives back the error.
If you create that record you can fill all kinds of columns without that record being in the DB. That should never be a problem.
If you start to create related records, you have to make sure that it is saved to the DB, especially if you do not use Servoy sequences. This was always the case, so I think it is best for you to really check your record creation methods for this and add saveData() where/when it is really needed.
I think, instead, that a modification of this behavior of Servoy is a serious impediment to the migration towards the new version.
We have in production tens of solutions and the work load for these modifications is really excessive for one version variation. Servoy would have to always guarantee the compatibility towards the bottom.
To complicate the job ulteriorly, in version 3.1.6, to have been removed the possibility to try one word in all the methods in the window of dialogue ‘find and replace’ of the Editor (Scope radio buttons). The Help does not help: it still has the image of the old window.
I ask therefore if the previous situation cannot be restored.
What exactly is the “feature” that is no longer available? Immediate saving after a newRecord() call? That has never been a feature. That you relied on this behaviour was a bit dangerous in my eyes anyway. That’s what saveData() is for! To make sure it’s done. Everything else was left up to Servoy and the user clicking somewhere. I am really sorry to say that but I think this “technique” has to be made reliable anyway, because it never was.
But: to make your live pretty easy check out the really nice Search feature that was introduced in Servoy 3. It’s located in the method editor (as the last tab in the debug area) and it should allow you to quickly find newRecord calls and resolve the issue easily.
They are not in agreement with how much you say. The esplicit command newRecord () in a method would have immediately to create the record in the DB. The innovations of Servoy are always excellent, but is incredibly laborious to audit the solutions every time one new release is released.
On the new system of search I admit it: me it was completely escaped and is one excellent functionality that it will help to make the modifications.
The esplicit command newRecord () in a method would have immediately to create the record in the DB.
Where did Servoy ever say this was a feature? To the opposite: when working with non Servoy sequences it states everywhere that if you need the sequence generated by the DB you have to call saveData() before you have access to that sequence. This only because newRecord() will NOT save the record immediately to the DB (if it did, you also had the sequence).
Another reason why this actually would be bad behaviour: imagine you have a column that is set to not allow NULL values. If you call newRecord() and Servoy saves immediately, the database would refuse every such record. YOu wouldn’t have the time to fill that not null column,
as Patrick said:
Servoy did never create the record directly into the DB, when you only do: controller.newRecord() (not in 2.2.7, not in 3.1.6 and not in 3.5)
It only saves when someone click outside the form, or navigate away to another form, or when you do: controller.saveData() (and now with > 3.1: databaseManager.saveData() )
Ok. I have lead of the tests and is true that version 2.2.7 did not create the record in the DB but the foundset in cache came managed in different mode.
This code as an example does not give error with the 2.2.7:
controller.newRecord();
oggetto = "Titolo nuovo articolo";
testo_news = "Testo nuovo articolo";
data_evento = globals.today;
fkid_menu1 = id_1;
fkid_menu2 = id_2;
articoli_to_chiavi.newRecord();
articoli_to_chiavi.level_0 = id_0;
articoli_to_chiavi.level_1 = id_1; articoli_to_chiavi.level_2 = id_2;
//Change form and Servoy save data!!
ApriArticolo();
As Servoy can be verified managed the keys correctly without to have saved the record master before and then the correlated record.
You say this code worked in 2.2.7 and does not in 3.1?
I would write this code as
var vNew = foundset.getRecord(foundset.newRecord());
vNew.oggetto = "Titolo nuovo articolo";
vNew.testo_news = "Testo nuovo articolo";
vNew.data_evento = globals.today;
vNew.fkid_menu1 = id_1;
vNew.fkid_menu2 = id_2;
// Now save data to make sure I have a PK that is used as foreign key
// for the relation however the sequences are managed
databaseManager.saveData();
var vNewRelated = vNew.articoli_to_chiavi.getRecord(vNew.articoli_to_chiavi.newRecord());
vNewRelated.level_0 = id_0;
vNewRelated.level_1 = id_1;
etc.
You say this code worked in 2.2.7 and does not in 3.1?
Exatly.
In all our solutions we have adopted this method of writing and not have never problems until version 2.2.7.
With version 3,1 instead it comes given back the error.
// Now save data to make sure I have a PK that is used as foreign key
// for the relation however the sequences are managed
databaseManager.saveData();
We have already begun from yesterday correcting the code just in this way. We think to employ little time for the corrections.
However I still emphasize that the behavior of the object foundset is changed but I repeat: I consider the problem closed.
