So - generally speaking - it is not advised to use lastval() at all?
At least not, if one is not 110% sure what happens in the application
now and on later modifications of the client application.
Thats a pitty, as I have only known lastval() for about 15 minutes when
I looked in the documentation for the sequence stuff.
On the other hand I ran today in troubles with sequences when I was
doing a bit coding on a migration from MS-Access DAO + JET to DAO, ODBC
With pure Access + DAO one can fetch the newly assigned AUTOVALUE by
simply reading it out of the newly created record right after AddNew and
With ODBC + PG. as backend the SERIAL is undefined between AddNew and
And the recordset points not to the new record after Update but to the
first record in the recordset.
I had to use PG's CurrVal respectivly LastVal which would be easier
without having to know the name of the sequence.
I'm happy that I read your post before using LastVal all over the
Dmitry Samokhin schrieb:
> Accordind to the release notes, "Use lastval() function to replace IDENTITY on 8.1 or later servers" was introduced in release 8.2.0205. This may cause incorrect results: "<...> assumes that your database does not expect any triggers to fire when the INSERT is executed. If a trigger does fire and if that trigger adds another row to a table, the @@IDENTITY global variable would be set to point to that new Identity value—not the one your INSERT generated. <...> work for simple situations, but not when your database gets more sophisticated".
> See "Managing an @@IDENTITY Crisis" on MSDN (http://msdn2.microsoft.com/en-us/library/ms971502.aspx) for more details.
> The PostgreSQL documentation states that the lastval() function returns the value most recently returned by nextval in the current session. It works the same way as the @@IDENTITY variable in MSSQL. The currval(...) function returns a value of the explicitly specified sequence, this is exactly what we need.
> Please consider to revert the code.
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
In response to
pgsql-odbc by date
|Next:||From: noreply||Date: 2007-05-06 06:46:54|
|Subject: [ psqlodbc-Bugs-1003103 ] copy_and_convert_field(...) destroys bind info for wide char varchar columns|
|Previous:||From: Hiroshi Inoue||Date: 2007-05-05 15:56:40|
|Subject: Re: Replacing IDENTITY with lastval()|