Thread: RE: [SQL] Getting primary key from insert statement

Perhaps I need to qualify my approach a little more.  Let me give an
example:

create table Status
(   StatusID                      int4 PRIMARY KEY DEFAULT
nextval('Status_seq'),   StatusName                    varchar(32) NOT NULL,
);

A normal insert in PostgreSQL would look like this:
Insert into Status (StatusName) values ('name of status'); 

An insert using Access97 would look like this:
Select nextval('Status_seq') into StatusID_value;   Insert into Status (StatusID, StatusName) values (StatusID_value,
'name of status'); 

Either way the StatusID or primary key is set the same way using the same
technique.  One method lets PostgreSQL determine the primary key while the
other method proactively determines the primary key is before the insert.

I accomplish this by trapping the "Before Insert" event in the form used to
add new Status records (the user is NOT entering the StatusID) and doing the
following:
Form.StatusID = getSeqValue('Status_seq')

Where getSeqValue() is defined below:
Public function getSeqValue(sequence_name as string)    // basically this function does the following:Select
nextval('Status_seq')into StatusID;   End function
 

-----Original Message-----From:    Herouth Maoz [SMTP:herouth@oumail.openu.ac.il]Sent:    Tuesday, June 08, 1999 2:27
AMTo:   pgsql-sql@postgreSQL.orgSubject:    RE: [SQL] Getting primary key from insert statement
 
At 23:10 +0300 on 07/06/1999, Michael J Davis wrote:

> I have been using this technique for years in Oracle (select next
value from> the primary key sequence and insert using this primary key).  I
like this> approach.  I don't think a transaction is needed.
I don't know what mechanism Oracle uses. Perhaps even a transaction
is notneeded (although logically, the two operations should be one, so as
not toallow the failure of the insertion, if only to save on unused key
values).
But doing things like that on the client side means that there is nological connection between the sequence and the
table.Anybody is
 
free toenter any primary key, and a mistake in one of the front ends will
causeinconsistency in the database. The theory of databases asserts that
youshould try to insert the logic and constraints of the organization's
datainto the backend.
I know that this should mean that in fields declared "serial",
values otherthan the default should not be allowed. Perhaps this should be
addressed innew versions of Postgres somewhere.
Herouth
--Herouth Maoz, Internet developer.Open University of Israel - Telem projecthttp://telem.openu.ac.il/~herutma

At 19:23 +0300 on 08/06/1999, Michael J Davis wrote:


> I accomplish this by trapping the "Before Insert" event in the form used to
> add new Status records (the user is NOT entering the StatusID) and doing the
> following:
>
>     Form.StatusID = getSeqValue('Status_seq')

Thus, you do it in the frontend. Six months later, a programmer writes
another form that accesses the same table, and fails to do so, or leaves it
to the user. Or he decides that he has a better number generator to use.
There are errors. Perhaps his form generates numbers which the sequence has
not yet reached. Conflicts ocuur. Boss unhappy.

That happens because you failed to centralize the logic of your database.

As I said, the "serial" datatype is not a complete fail-safe, because it
still allows entering non-sequence values. But at least it's a step in the
right direction. Putting the logic in the client side is the wrong thing to
do.

To finish in a humorous note, I wouldn't use programming practices
encouraged by Microsoft products as pillars of truth...

Herouth

--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma