insert_id not working

[eluser]Fred Riley[/eluser]
Thanks to all for the replies. I do call insert_id() after the insert operation, in a view after the controller to add a new user record is run. This is using ion-auth - the user fills in a registration form, on submit that form runs a controller to insert a user, then calls a view to tell the user that s/he's registered ok and showing them their details. The row is definitely inserted because I see it in the table, and affected_rows() returns 1.

The call to insert_id() worked fine in a previous application I developed in CI 1.7, identical code, which is why I was so surprised that it falls over in my latest app. The user table being inserted into does have an auto-increment primary key.

It's all a bit of a mystery, but maybe it's an ion-auth thing. I'll have to check it after the weekend.

Fred

[eluser]Aken[/eluser]
[quote author="Fred Riley" date="1359107068"]I do call insert_id() after the insert operation, in a view after the controller to add a new user record is run.[/quote]

1) Don't call stuff like this in the view. Your controllers and models work the logic, then send it to the views for display only.

2) When I say after, I mean immediately after. E.g.:

Code:

$this->db->insert('table', $data);
$id = $this->db->insert_id();

If you don't do that, you run the risk of something else changing the result.

[quote author="Fred Riley" date="1359107068"]The call to insert_id() worked fine in a previous application I developed in CI 1.7, identical code, which is why I was so surprised that it falls over in my latest app. The user table being inserted into does have an auto-increment primary key.[/quote]

Considering how different 2.1.3 is from 1.7.x, you can't rely on everything being exactly the same.

[eluser]CroNiX[/eluser]
My guess is it has something to do with ion auth when creating a new user. It might be doing an additional query somewhere before it returns, so insert_id() wouldn't be what you are expecting. I haven't used it so not sure how it works. When a new user is created in ion auth, does it return anything like an array? It might have the users new id.

[eluser]Harold Villacorte[/eluser]
I just put this code in my current project and it works great:

Code:

public function insert_role ($post) {
  unset($post['add']);
  $query = $this->db->insert('roles', $post);
  $id = $this->db->insert_id();
  return ($id) ? $id : FALSE ;
}

[eluser]Fred Riley[/eluser]
Thanks to all for the replies.

[quote author="Aken" date="1359108875"]

1) Don't call stuff like this in the view. Your controllers and models work the logic, then send it to the views for display only.[/quote]

Ok, that's told me. Slap on the wrist taken. No logic in views, ever.

Considering how different 2.1.3 is from 1.7.x, you can't rely on everything being exactly the same.

Er, yes, I'd kinda figured that, after having spent many hours painstakingly copying and pasting, doing mass search/replace, and tweaking code from the 1.7 version to 2.1. I've still not got the 2.1 version running properly and suspect that many more hours of work lie ahead. I do hope that there'll not be such major changes when v3 finally comes around, as a major reason for adopting CI over 'freeform' PHP, as I used to write, was the promise of easier maintainability and scalability. Having to do a semi-rewrite of the application for v2 has dented that promise for me, but I'm too far down the CI road now to turn away.

Fred

[eluser]Fred Riley[/eluser]
[quote author="CroNiX" date="1359133195"]My guess is it has something to do with ion auth when creating a new user. It might be doing an additional query somewhere before it returns, so insert_id() wouldn't be what you are expecting. I haven't used it so not sure how it works. When a new user is created in ion auth, does it return anything like an array? It might have the users new id.[/quote]

It does, yes, and now that you mention it, it's obvious that I should be getting the new user id array element rather than using insert_id() - D'OH!! :red: My only excuse is that it was past 11pm when I posted my query and I was ready for the land of nod

Fred

[eluser]Aken[/eluser]
[quote author="Fred Riley" date="1359410627"]I do hope that there'll not be such major changes when v3 finally comes around, as a major reason for adopting CI over 'freeform' PHP, as I used to write, was the promise of easier maintainability and scalability. Having to do a semi-rewrite of the application for v2 has dented that promise for me, but I'm too far down the CI road now to turn away.[/quote]

There will be some things that need to be revised. You can get a good idea from these files:

https://github.com/EllisLab/CodeIgniter/...de_300.rst
https://github.com/EllisLab/CodeIgniter/...ngelog.rst

You can always use the 3.0 code as it sits right now and work on moving your application directly to 3.0. Though that may provide more headaches for you, since you'll get new errors also (like the Session library is now a driver, and your authentication library will probably throw errors because of it). It could be more work, but it would save you a step from needing to upgrade again in the near future.