Fatal error call to a member function insertid ...
Fatal error call to a member function insertid ...
Same/similar error as reported here, but without using any joins: https://datatables.net/forums/discussion/39387/fatal-error-call-to-a-member-function-insertid-on-null. Full error:
PHP Fatal error: Call to a member function insertId() on a non-object in /var/www/html/new/includes/editor/php/Editor/Editor.php on line 1601
Upgrading from Editor 1.5 to 1.6, haven't been able to pin down what's causing it yet. The referenced post had to do with Mjoin, which I'm not using. Trying to troubleshoot, but I don't think I can use the datatables debug area since it's server-side scripts.
Thoughts?
This question has accepted answers - jump to:
Answers
Can you enable the debug mode in 1.6 and show me the SQL? That error suggests that there is / was not insert, or no primary key value was returned.
Allan
It was not inserted - when performing a manual insert, the user account I have does not have write access to the schema. groan
Circling back with the DBAs, will report here if this is the root cause.
Interesting. I would have expected there to have been an SQL error generated under those conditions and that should have been removed back to you rather than this obscure error.
Allan
Yeah, something is a bit wonky.
Access issues fixed, tested by doing a manual insert. The first (new) problem is that the manually inserted row does not appear in the datatables UI (yes, I refreshed). I added a new row through editor, and the new row was added to the UI and database, ID=2, but the first record (ID=1) is still absent.
The original error on insertId may be caused by trying to insert a varchar into an int field. To your point, I'd expect a different SQL error.
Still attempting to correct these (minor) issues to be able to pinpoint the problem.
This makes no sense. I added a validator, reloaded the page (after already doing a page reload, and clearing the cache) and the 'missing' record appeared.
Added the validators to prevent varchar into an int and everything looks good.
I believe the original error may be due to the varchar into an int. If it helps, I'm using Oracle and OCI8. I can perform any test if you want to troubleshoot, but in the end the problem is bad SQL.
When you did the manual insert, did you also commit it (I'm not sure that is the correct terminology...). That tripped me up massively when I first used Oracle - I'd do an insert (I was using DataGrip) then read it back successfully in DataGrip, but it couldn't be seen anywhere else. Lost about two days to that!
Allan
The commit issue was causing the 'delay'. After a long period of time, an inserted (but un-commited) record would eventually be automatically be commited.
Still have the lingering issue of error handling with Oracle - like I said, if you want help testing/troubleshooting, let me know, happy to try anything.
I've improved the error handling for Editor 1.6.2 which will be released later this month. At the moment SQL errors are incorrectly being swallowed by the code and we get the generic error that you reported above instead. 1.6.2 will show the SQL error and stop the execution at that point.
Allan