There was a behavior change in 3.5.8 compared to 3.5.7
I don’t know if this is a bug or that the previous situation was not correct, but now I’m getting errors that didn’t get in 3.5.7
See the following situation:
In my database I have the following records:
rittenstatistiek_per_type_id rittype rittenstatistiek_id
---------------------------- ------- -------------------
69228 F 1
The combination (rittenstatistiek_id, rittype) is UNIQUE (database constraint)
databaseManager.startTransaction()
var _statistiek_id = 1
_rittenstatistiek_per_type.find();
_rittenstatistiek_per_type.rittenstatistiek_id = _statistiek_id
_rittenstatistiek_per_type.rittype = 'T'
_rittenstatistiek_per_type.search(true, false)
if (_rittenstatistiek_per_type.getSize() == 0) // This condition is true
{
_rittenstatistiek_per_type.newRecord()
_rittenstatistiek_per_type.rittenstatistiek_id = _statistiek_id
_rittenstatistiek_per_type.rittype = 'T'
}
:
:
// Some additional field settings in _rittenstatistiek_per_type
:
:
_rittenstatistiek_per_type.find();
_rittenstatistiek_per_type.rittenstatistiek_id = _statistiek_id
_rittenstatistiek_per_type.rittype = 'F'
_rittenstatistiek_per_type.search(true, false)
if (_rittenstatistiek_per_type.getSize() == 0) // false
{
_rittenstatistiek_per_type.newRecord()
_rittenstatistiek_per_type.rittenstatistiek_id = _statistiek_id
_rittenstatistiek_per_type.rittype = 'F'
}
:
:
// Some additional field settings in _rittenstatistiek_per_type
:
:
databaseManager.saveData()
databaseManager.commitTransaction()
In 3.5.7 the above coding went OK. A new record with rittype ‘T’ was created and rittype ‘F’ was updated.
In 3.5.8 I get an error on saveData(). Database is trying to INSERT a record with rittype ‘F’ which is wrong. It should do an INSERT with rittype ‘T’ (and it did an INSERT in 3.5.7)
It looks like the newRecord() was partially lost and the find/search on rittype ‘F’ has replaced some data of the newRecord.
I could solve this problem by putting a databaseManager.saveData() after the handling of the rittype ‘T’ part, but I still would like to know if the 3.5.7 didn’t work like it should have worked or that this is a bug in 3.5.8
Hi.
I’m not sure if this is the answer, but Servoy did change something in the way new records are created when you use ‘DB Identity’ for the PK (in other words, the back-end database is creating the PK’s, not a Servoy Sequence.
I had this issue at a client I was testing upgrading from 3.5.5 to 3.5.8.
For me the issue was some auto-enter values based on a self-join that stopped it working.
I think you need to make sure that all PK’s are generated correctly and SAVED before you change any other values.
In this case I’m using Servoy Sequence Numbers and not DB Identity fields.
In the beginning I wanted to use also DB-Identity, but I changed it, because I needed the PK-field value before the saveData(), and only on saveData() you get the DB-Identity value.
what is this: _rittenstatistiek_per_type ??
is that a related foundset??
Because then what you describe could easily happen. I dont know if that is changed somehow
But if you create a new record on a relation. It tries to insert a record that follows that relation and if that relation is made for type “F” then yes it will create one with type “F”
I dont know why that override you do is not working, setting it to type “T”. But the code itself doesnt sound right to me.
martinh:
I could solve this problem by putting a databaseManager.saveData() after the handling of the rittype ‘T’ part, but I still would like to know if the 3.5.7 didn’t work like it should have worked or that this is a bug in 3.5.8
Johan,
Just like you did in your example, you added the saveData().
I did that also, and then it works.
But in 3.5.7 it already worked without the saveData()
i am not completely sure why that is
But you create a new record then set data and you then suddenly go into a find on that same foundset. it is way better to handle your stuff first (doing a savedata)
but going into find should trigger a saveData so that is still a bit of a question.
At what time if you dont do savedata do you see the wrong insert happening?
In the original coding you can see that the saveData() is just before the end of the transaction.
There I got a database error (duplicate on a UNIQUE index)
The combination (rittenstatistiek_id, rittype) is UNIQUE (database constraint)
In the above situation a new record with rittype ‘T’ was created and rittype ‘F’ was updated (rittype ‘F’ already existed in the database)
I get an error on saveData(). Database is trying to INSERT a record with rittype ‘F’ which is wrong. It should do an INSERT with rittype ‘T’
jcompagner:
i think find doesnt go into find because it has unsaved data and you are in a transaction (also autosave off?)
There was another change in my source also, which I realize now that is important in this case.
That is that I put indeed autoSave OFF almost at the same time as when I updated to 3.5.8
When I see your reply, I think that this was the problem that caused the error.
When autoSave ON, record is directly written to the database and so that find() doesn’t give an error
Now with autoSave OFF, and the find() is not checked, it looks like a different behavior, but in fact the find() returns false, so I’m not in findmode and the rittype fields is overwritten by ‘F’
So it is not a bug; it is the autoSave that causes this behavior