in reply to Sequences, last_insert_id, SQLite, and Oracle

You can keep the flow the same, but the actual SQL will be different.

In SQLite: 

insert into table ...
select last_insert_rowid();

[download]
In Oracle, assuming you have setup a trigger to emulate the auto_increment feature: 
insert into table ...
select table_seq.currval from dual;

[download]
Note that you have to name your sequence predictably based on the table name to do that. We just append "_seq" to the table name to get the sequence name.

If you *really* want to be clever, you could set up an oracle package to contain a global session variable, and then make all your auto_increment-emulation triggers update that variable. Then you can write a last_insert_rowid() function to return that value. But you still need the "from dual" in oracle, so the sql is still different.

Replies are listed 'Best First'.
Re^2: Sequences, last_insert_id, SQLite, and Oracle
by etcshadow (Priest) on Jun 15, 2005 at 01:20 UTC
    This is no good if you have concurrent sessions both inserting into the same table. You have no way of knowing that in between when process A inserted into the table and when process A checked the last value of the sequence, that process B hadn't inserted a row and caused the sequence to jump.

    The way to handle this is to catch the sequence value that was actually used by the trigger, atomically as part of the insert statement itself. Oracle DOES IN FACT provide a way of doing PRECISELY THAT. You can write an insert statement like "insert into foo ... returning id into ?", and then use in/out binding (see DBI docs for bind_param_inout) to catch the value that is spit out into that trailing bind value.

    This method works, reliably. It is easy enough. None of the other methods in this thread do work reliably. 

    ------------
:Wq
Not an editor command: Wq

    [download]
[reply]
[d/l]
      That is complete and utter misinformation.

      Fortunately Oracle has a much better grasp on concurrency issues than you do.

      Oracle sequences are designed to support heavy transactional loads. One thing they sacrifice for this is guaranteed serial-ness of the numbers. Each session gets its own cache of sequence numbers, so that it can avoid needing to lock the sequence every time you ask for a new number.

      The number you get from NEXTVAL will be the number you get from CURRVAL, and no other sessions can affect your value, because it is private to your session. You even get an error if you ask for the CURRVAL before you have asked for a NEXTVAL in this session.

[reply]

In Section Seekers of Perl Wisdom