From: | Jeff Eckermann <jeff_eckermann(at)yahoo(dot)com> |
---|---|
To: | psql-odbc(at)postgresql(dot)org |
Subject: | Dealing with Insert Problems with Access |
Date: | 2004-04-20 14:56:59 |
Message-ID: | 20040420145659.19996.qmail@web20806.mail.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-odbc |
I have just deployed a MS Access client-server
application with a PostgreSQL 7.2.4 backend (not that
the version matters in this case). I am bumping up
against the famous "#Deleted#" in every field issue
that comes up on this list from time to time.
The problem is that, in this application, the data can
be quite sparse for some records, with the result that
some records only differ in their primary key value,
which is a serial in PostgreSQL. When a new record
gets created, Access fails to find a unique record
with the same data values, so the error.
I don't want to move to unbound forms/controls, so I
am looking for a minimalist way to solve the problem,
which would involve adding some "before insert" code
which will specify a unique value to be inserted. I
am looking at two choices:
* Do a "nextval" call to get the next serial value,
and specify it explicitly. This involves an extra
network round trip (and an extra connection), but has
the benefit of being unequivocal.
* Add a timestamp field to the table, and specify the
applicable value in my vba code.
This app is not intensively used, so either solution
would probably work fine in practice. Is there any
reason why I should prefer one over the other? Or is
there another kind of solution altogether that I could
try?
TIA
__________________________________
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25
http://photos.yahoo.com/ph/print_splash
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Sorokin | 2004-04-20 22:50:56 | Problem updating a large binary field (PostgreSQL, ODBC, VC++) |
Previous Message | David P. Lurie | 2004-04-19 14:57:32 | "Use Declare/Fetch" option |