Re: @@IDENTITY (Was: Access - ODBC - serial problem)

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Ed Brown <ebrown(at)arcompanies(dot)net>
Cc: Philippe Lang <philippe(dot)lang(at)attiksystem(dot)ch>, <pgsql-odbc(at)postgresql(dot)org>
Subject: Re: @@IDENTITY (Was: Access - ODBC - serial problem)
Date: 2004-04-12 16:44:37
Message-ID: Pine.LNX.4.33.0404121042530.14195-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-odbc

On Sat, 10 Apr 2004, Ed Brown wrote:

> I agree with the strangeness of Microsoft's name, but the capability is
> useful. What I do in a case like this is use the transaction capability. If
> you do
>
> Begin transaction;
> <Do the insert>;
> Select max(oid_column_name) from table;
> Commit work;
>
> You are guaranteed to get the correct ID back in any system that supports
> transactions. Because all "real" databases support caching, it's
> computationally inexpensive, unless you have a trigger that will insert
> another record behind your back.

In Postgresql, this is NOT I/O inexpensive, but results in a seq scan of
the whole table to find the max value.

select oid_column_name from table order by oid_column_name desc limit 1

is computationally and I/O inexpensive if the table has an index on that
field.

However, I think you have to be in serializable transaction mode for that
code to be gauranteed not to get the wrong data. But I'm not certain on
that one.

In response to

Responses

Browse pgsql-odbc by date

  From Date Subject
Next Message Tom Lane 2004-04-12 17:27:56 Re: @@IDENTITY (Was: Access - ODBC - serial problem)
Previous Message Bruce Momjian 2004-04-10 21:32:37 Re: fixes for psqlodbc-07.03.200, patch