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

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.

Ed
----- Original Message -----
From: "Philippe Lang" <philippe(dot)lang(at)attiksystem(dot)ch>
To: <pgsql-odbc(at)postgresql(dot)org>
Cc: "scott.marlowe" <scott(dot)marlowe(at)ihs(dot)com>
Sent: Saturday, April 10, 2004 1:59 AM
Subject: Re: [ODBC] @@IDENTITY (Was: Access - ODBC - serial problem)

> For reasons unfathomable to modern man, Microsoft chose @@IDENTITY to
mean,
> not the current user, as I or you or any sane person would expect, but
to hold
> the incremented value of an autoincrementing column fed by an insert.
Another
> triumph in orthogonally named things from Microsoft.
>
> Anyway, what the original conversation was about was getting back the
auto
> increment value from pgsql via ODBC with access on top. The problem
being
> that postgresql doesn't have a simple "what was the autoincrement I
just put
> in" but requires the user to either use the system catalogs to look up
the
> sequence name and then use currval on it, or something like a plpgsql
function
> to insert your data.

-----------

Without a way of getting the autoincrement from the ODBC driver, there
will always be cases, when adding data to a table through a linked
table, where the data that appears onscreen is not the one that has been
added to the table. And this until you requery the whole table.

- After an insert, Microsft ODBC driver issues a "SELECT @@IDENTITY".

- After an insert, Postgresql ODBC driver reads the data based on the
values that have been inserted. There are cases were these values
already existed in the table before the insert, and so the autoincrement
fetched may not be correct.

Is there anything that can be done at the driver level?

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match