NULL values treatment
NULL values treatment
I inherited an old website that uses datatables. Old, probably ten years old. I just uploaded the configuration, the uploaded code is ojuxax.
That datatable and editor work against an Oracle database. The table in that database has a few Not NULL columns.
The Editor in the datatable has an editor that sends create queries where some of the fields in the table are not included. Say, out of 15 columns, only 12 are in the query.
When the Editor in the datatables sends CREATE queries to the table. The table has a trigger that in insert fills the values that were not provided by the datatables editor create.
It needs to be done that way because the table has a geographic component that has some other implications that there is no need to discuss here
It works. It can create new rows as right now.
I want to modernize that website and I am implementing everything with the latest versions of datatables.
I have a test website where I can recreate the query 100% identical to the one in the old website.
However, this datatables editor with the latest version gives me back a ORACLE message complaining about the not NULL fields missing in the query
My sense is that there is something in the new datatables Editor that handles NULL, or not listed values in a different manner.
So, I need to find a way for how to handle those not null values.
Any wisdom on this?
Answers
I'm afraid nothing immediately springs to mind here. Are you using our PHP libraries? Could you add
->debug(true)
just before the->process(...)
call, and then show me the JSON response for when you do an edit please? It will show the SQL that is being generated and executed. That should give me a better idea of what is going on.Thanks,
Allan
Here are the JSON responses.
create and edited for both the old (that works) and the new (that does not work).
Just one more comment. Multiple editors, with create, delete and edit work on this website work.
The only one that does not work is the create with one of two NOT NULLfields not included in the query.
In the old website, the fields that are not included in the query get filled by a trigger in the database. The trigger kicks in ON INSERT.
What is really interesting is that the old script does not contain the variable GLOBALID, neither the variable OBJECTID. Noneless, they get created on insert.
The new script does not creates them on insert and just says " i need objected and globalid
To confirm my understanding, both
GLOBALID
andOBJECTID
should be filled in by triggers. Is that right?If so, in your PHP code (assuming you are using our Editor libraries) add
->set(false)
to theField
for each of those two columns. That will stop Editor attempting to write to them at all and let the triggers do what they need to do.Allan
Thanks Allan. I added the ->set(false).
I can exactly see in the JSON response how it works and how it ignores the GLOBALID field and how it does not when ->set(false) is not there.
However, the Editor still does not work. and still complains about the field being NULL.
I know that common sense would say that something is wrong with my trigger, and I would accept that answer, if the old website, with the old Editor would not work, but it does.
I see how this is a weird question.
So to confirm - when you insert a row (with the
->set(false)
) it will tell you the field cannot be null. But the trigger should be filling it in?Is the trigger running at the right time - i.e. BEFORE INSERT (or whatever the Oracle equivalent is)? I'm wondering if we've tightened up the SQL we generate and it used to insert an empty value or something, but no longer.
Can you show me the INSERT that is being generated and also your SQL trigger code?
Thanks,
Allan
How can I show yo u the insert?
Is this what you are talking about?
this is the one that does not work in a recent Editor version
this is the one that does work, in a very old version of Editor
This is the trigger