One way - ugly - but maybe OK:
To create a new record, do a "insert" statement with enough known unique
values that you can the re-select it, then re-select it, edit out any funny
values, and work with the recordset / present the form.
The different ways the ID # were loaded don't matter that way. Note that
defining the ID field in PostgreSQL as the primary key will prevent some
other weird ADO behavior where Access via JET knows which records to update
but PostgreSQL via ODBC doesn't.
At 04:49 PM 8/22/06, Andreas wrote:
>Thanks, I did it that way but I'd like to have a workaround that doesn't
>tie my application to one single RDBMS.
>My initial plan was to create an adodb-connection to the current db
>backend on start of my application and the rest of the program wouldn't
>need to be aware what RDBMS actually manages the data in this session.
>This would be postgres in my LAN and JET directly accessing MDB-files on a
>notebook pc where I'd rather not always run a server in the background.
>
>
>Johann schrieb:
>>Easiest way I've found is to read NextVal on the relevant sequence, and
>>use the value you get for the key field.
>>
>>Since the field will be loaded, the "default" function that assigns the
>>number, kind of like an Access Autonumber - will *not* override the value
>>you manually insert.
>>
>>So:
>>Get nextval on sequence
>>.addnew
>>recordset!idfield = thenextvalyougot
>
>---------------------------(end of broadcast)---------------------------
>TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq