Skip site navigation (1) Skip section navigation (2)

Re: ADO and sequences

From: "Johann" <johann(at)tygerpos(dot)com>
To: pgsql-odbc(at)postgresql(dot)org
Subject: Re: ADO and sequences
Date: 2006-08-23 03:42:51
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-odbc
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.
>>Get nextval on sequence
>>recordset!idfield = thenextvalyougot
>---------------------------(end of broadcast)---------------------------
>TIP 3: Have you checked our extensive FAQ?

In response to

pgsql-odbc by date

Next:From: Hiroshi InoueDate: 2006-08-23 08:39:36
Subject: Re: Parameters.Refresh and RETURN setof TEXT
Previous:From: Benjamin KrajmalnikDate: 2006-08-23 00:21:27
Subject: Re: ADO and sequences

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group