On 19/03/2010 11:35 PM, Little, Douglas wrote:
The update can’t then locate the row (timestamp mismatch), and displays
the ‘write conflict’ error.
Change the ODBC driver settings to issue updates by primary key, and the
issue goes away. IIRC it's done in some backward-ish way like turning
of
When connected to ODBC source Access ignores locking steps. I don't think
that's the problem.
If memory serves, when Access is building the UPDATE command automatically the
WHERE clause includes every single column being updated when the old values,
something like this
Update set col =145, co
On Fri, Mar 19, 2010 at 11:12 AM, jus...@magwerks.com
wrote:
>
> The bigger problem is using time stamps to find the record for updating
>
> Timestamps will not be unique as more than 1 record can have the same value
>
> I suggest changing the updating method to use a unique key.
MS-Access achiev
The bigger problem is using time stamps to find the record for updating
Timestamps will not be unique as more than 1 record can have the same value
I suggest changing the updating method to use a unique key.
Message from mailto:douglas.lit...@orbitz.com "Little, Douglas"
douglas.lit...@orb
Hi,
We've been struggling with an MS Access 2007 app that updates a PG table. It
was working, and then it wasn't.
It looks like we recreated the table without specifying the precision on the
timestamp columns.
PG is defaulting to timestamp(6), which doesn't work with MS Access. The
finest p
