PHP error
PHP error
menashe
Posts: 196Questions: 43Answers: 2
in DataTables 2
I keep getting the error message shown below:
I am assuming that it is because the value for parameter 5 (item_id) is not surrounded by quotes, but I cannot figure out how to fix.
Thanks.
Answers
I'm not sure to be honest! There is nothing that immediately stands out as wrong there.
Can you show me:
Thanks,
Allan
Oh boy! The PHP Editor file is easy--but big.
My web site used to display Table A, which then had one or more children from Table B, which in turn had one or more from Table C... This went five or so levels!
I decided that was a ridiculous way to enter data (on five different Editor forms), so I JOINed everything together in the included PHP.
I am not sure what I would give you as a SQL dump.
By the way, the issue occurs for ADDing; EDITing and existing record works.
Could you replace the contents of the
DataTable/Driver/PostgresQuery.php
file that you have with the below please?It won't fix the issue - rather it adds some more debug - I'm wondering if it is the primary key query that is the issue.
With that change in place, could you execute an edit command and then copy / paste the full JSON from the response here please?
Here you go. I assume that you meant ADD, not EDIT; the Edit didn't produce this JSON.
(I could not figure out how to retain the JSON formatting.)
I think it is this:
Could you replace with:
More correctly, I think the query to get the primary key name isn't correctly doing a split on the name if an alias is used, without the
as
. That is something I can look at fixing (assuming this addresses the issue!).Allan
Same error.
I keep looking at the JSON. Every single value is surrounded by quotes, except for the "item_id".
Why is that? Isn't that the issue?
I don't really see why an integer rather than a string would make a difference, but then I also don't see anything else that is causing an issue!
Could you try this varient please? I've converted the integer to be a string and corrected the debug order.
Hi Alan,
I have not (yet) tried the above--I trust your judgement that it seems unrelated.
Besides, I have trying out various scenarios and staring down the code. I did notice that even in EDIT mode (which I had said that it works), the PACKAGING_DETAILS table is not updated--it is not even included in the resultant JSON!
Does that tell you anything?
Well... I'd just be surprised, but I've been known to be wrong before (like on an hourly basis ).
The JSON structure for a row returned from the initial load action is different from after the create or edit commands? That is odd... And the load is definitely happening from the same script?
Hi Alan,
I did try it yesterday, and it did not help.
Exactly! The initial load contains all of the values from the PACKAGING_DETAILS table (I did not try putting a value in the database for each column, but the JSON record is there and has the existing values!
For the EDIT, there is simply no JSON structure for that table.
Can you show me the initialisation Javascript for your DataTable and Editor instances please?
The PHP server-side code uses exactly the same methods for getting the row data after a create / edit as it does when loading there data. There is something odd going on if the data structure returned from each is different.
Are you able to PM me a link to the page? It might help if I can see it in action.
Thanks,
Allan
I currently run on localhost, albeit using Apache, so I'm not sure about a link.
So... let me first send the Javascript.
It won't let me send that much data!
Can you use Pastebin or something similar?
Allan
I hope that this works!
https://pastebin.com/embed_js/k1F6TmBa
They are both using
server_side/scripts/items.php
which is immediately what I was looking for. I don't really understand why the script would return a different structure for the rows to be honest.If you are able to put it up on the web somewhere so I can debug it, that would be really useful.
Alternatively, a zip of the package and a dump of the database tables in question so I can easily run it locally, would be an option. allan at thisdomain.net will come to me.
Allan
Hi Alan,
Please don't ask what changed--I went through every line of code, PHP and Javascript, making changes here and there.
The Bad Parameter error is gone!
Still cannot save packaging_detail table--it's not in the JSON.
Is there any chance that this a bug, or is something that I have somehow (still) just missed?
Its certainly possible. Can you show me the HTTP request parameters and the return JSON with the debug SQL statements in the current state?
Allan
HTTP Payload - Form Data tab: (You see the values 'test02' and 'test03')
2 requests
82.3 kB transferred
81.7 kB resources
And this is the HTTP Response tab, which has all of the queries found under the Preview tab:
(Too big - last part follows in next comment.)
I believe it is because
packaging_details
is a join ofpackaging_dimensions
. Whereaspackaging_dimensions
is a join of the host table (items
) so it works, but because of the second level of nesting, unfortunatelypackaging_details
does not work at this time.This is the relevant code - it uses the host's primary key, and if that doesn't match the join it attempts to use one of the field values submitted. Neither case applies here, so unfortunately it can't match and doesn't run that nested insert.
I don't immediately have a solution for this I'm afraid - it might require a fair amount of reworking in that code to allow such a use case to work.
What you could consider doing is writing the
packaging_details
in manually using apostCreate
event. You would need to look up the newpackaging_dimensions
primary key value from the newitem
id, but that would work.Allan
Alan
Thank you for tracking it down. I'm tempted to look at the Editor.php code myself, but...
Let me ask: What would be involved if I wanted to write a "wrapper" (?) to use native SQL, so that I don't ever use Editor PHP?
I know that I've seen that the back-end database can be accessed in any fashion, but I do not (yet) have a handle on what that involves.
If you want to write your own backend code, the Editor client / server data exchange protocol is documented here. It is quite possible, and depending on how dynamic you want to make it, it can be a viable option.
The goal with the Editor PHP libraries is not to cover every single use case - that simply wouldn't be feasible. It should however cover 80+% of them. So there will be some cases (possibly this one) where some code does need to be written.
Its up to you to decide if you want to go that route or explore using
postCreate
to add the row in.Allan
Please clarify how I would manually enter the row in
package_details
inpostCreate
?I am drawing a blank!
I would strongly recommend using "postCreate" or "writeCreate" in this situation. I mean dropping all of the benefits of Editor just because it doesn't work in one special use case seems to be "overdone" in my opinion.
For special cases I have been using "writeEdit", "writeCreate", "postEdit" and "postCreate" and many of the other events listed here https://editor.datatables.net/manual/php/events
I use them to make custom SQL updates, inserts and even deletes on many occasions. No issues with that. Makes Editor even more flexible to use.
Agreed!
My question was--please refresh my memory or show a brief example of making a custom SQL update from
postCreate
?(I might just be giddy from the election results! )
Here is a helper function from my own coding that uses Editor's db handler to process linked contracts on "writeCreate" and "writeEdit" (so BEFORE the data have been read back from the server which is what I want).
Of course this isn't exactly your use case but shows you how flexible this can be done. Here I need a table linking a contract to other contracts and vice versa. Those links need to be "double" to work when the links are displayed in an Mjoin. That of course is something Editor is not expected to do - and will never be able to do. At least it wouldn't make any sense ...
And the helper function with the additional processing:
This uses Editor's "raw" and "insert" methods. But you can also use your own db-handler of course.
You will need the data from the (incomplete) INSERT or UPDATE, so "postCreate" is better for you. But that doesn't make a big difference. Just use the data from $row instead of $values.