RE: [SQL] Getting primary key from insert statement - Mailing list pgsql-sql

From Michael J Davis
Subject RE: [SQL] Getting primary key from insert statement
Date
Msg-id 93C04F1F5173D211A27900105AA8FCFC14558C@lambic.prevuenet.com
Whole thread Raw
List pgsql-sql
I agree.  But, in practice Access97 does a very poor (let me rephrase this,
completely unacceptable) job of handling inserts within forms if the primary
key is not included in the insert statement.  In all the discussion about
what is the proper way to this, I have not yet seen an example or suggestion
that "works" in all cases with Access97.  I'll bet that many of the other
third party GUI interfaces work pretty much the same way as Access97 (insert
a record and the re-select the record using the values provided in the
insert statement).  If the application does not re-select the record then
updates resulting from triggers will not be shown.  Most of these
applications are not smart enough to ask for the primary key of the newly
inserted record and then re-select the record based on this key.  This is
because the technique for getting the primary is different for each database
if it is even available.  

I am sorry you (and others) don't care for this approach, but so far, it is
the only approach that works.  As for Microsoft, I dislike (okay, I even
hate some of them) many of the choices they make and I prefer to use other
products when they are available.  But for the moment Access97, even with
its inherent draw backs, is one of the best database front ends on the
market for the money.  

I really want to start using a real database for the backend.  I have
researched many options and feel there are really only two choices worth
considering, MS SQL Server or PostgreSQL.  I have chosen PostgreSQL.  Please
don't make me regret it :-).  Like or not, I am stuck with Access97 and
would really like to use PostgreSQL as the back end.  So, we have two
choices, find solutions that work with Access97 or continue to hash out what
is the "best" way to approach these types of situations.  I am willing to do
the later only as long it leads to better solutions.
Is it reasonable for me to ask others to provide viable alternatives rather
just complaining about the approaches I have chosen to take :-)?  I also
think it is reasonable to expect programmers to know how to properly
interact with the database.  I.e. they should know or be trained on the best
way to insert records into the database.
-----Original Message-----From:    Herouth Maoz [SMTP:herouth@oumail.openu.ac.il]Sent:    Tuesday, June 08, 1999 10:40
AMTo:   Michael J Davis; pgsql-sql@postgreSQL.orgSubject:    RE: [SQL] Getting primary key from insert statement
 
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
writesanother form that accesses the same table, and fails to do so, or
leaves itto 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 hasnot 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 itstill allows entering non-sequence values. But at least it's a step
in theright direction. Putting the logic in the client side is the wrong
thing todo.
To finish in a humorous note, I wouldn't use programming practicesencouraged by Microsoft products as pillars of
truth...
Herouth
--Herouth Maoz, Internet developer.Open University of Israel - Telem projecthttp://telem.openu.ac.il/~herutma


pgsql-sql by date:

Previous
From: Herouth Maoz
Date:
Subject: RE: [SQL] Getting primary key from insert statement
Next
From: Bob Kruger
Date:
Subject: Updating non atomic values