Insert Table-Event anomalies

Classic Servoy
1

I have 2 tables that relate to each other using a foreign key constraint in the database.
I am using the Insert Table-Event to populate another table using the rawSQL plugin. So far so good.
Now I do like to use database sequences instead of Servoy sequences and when I fill the table with the event on it with a method I get errors on my rawSQL inserts.
The errors indicates that the record is not written to the back-end yet and my foreign key constraint prevents any records to be written to the other table.
Thinking about it I thought this makes sense because the is a pre-save trigger and the rawSQL plugin talks straight to the database…BUT. When I insert a record just by manually creating a record on the form, type in some data and click out of the field it suddenly all works!

It seems one of the 2 behaviors is a bug.
I hope it’s the first behavior but I can imagine it would be the second.
How would Servoy otherwise rollback an insert (unless they do use a database transaction when writing to the back-end database).

Servoy Developer
Version 3.5.6-build 519
Java version 1.5.0_13-119 (Mac OS X)

Case created with ID: 135913

2

What do you mean with inserting the record manually? Typing into a related field?

I guess the parent record and child record are both created in memory. When you then save, Servoy first creates the parent record in the database and after that the child record (to prevent the contraint issues :) ).

So, as far as I can tell your your description, it all behaves as it should.

Paul

3

Hi Paul,

With manually I mean I hit the New Record button (toolbar) in the form of Table A (the one with the trigger on it).
Type in some data of that table and click out.
And yes this all works.
Now try the same with a method:

controller.newRecord();
// fill some data (when needed)
databaseManager.saveData()

Fire this method and I see foreign key constraint errors.

Keep in mind I am populating a related table not over a relationship but directly using a table event.

4

Mmm, now I understand. Sounds odd indeed.

Tnx for allready registering a case.

Paul

5

Robert,

I could not reproduce this.

Note that we are planning to extend the triggers set with post-event triggers (current table triggers are pre-event triggers, the database has not been updated yet).

Rob