Re: [pgadmin-support] Is earlier error "Could not locate the record for deletion" fixed?

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Knut Nymoen" <nymoen(at)systek(dot)no>
Cc: <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: [pgadmin-support] Is earlier error "Could not locate the record for deletion" fixed?
Date: 2002-06-12 07:20:43
Message-ID: D85C66DA59BA044EB96AB9683819CF610150E2@dogbert.vale-housing.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

> -----Original Message-----
> From: Knut Nymoen [mailto:nymoen(at)systek(dot)no]
> Sent: 11 June 2002 21:00
> To: Dave Page
> Subject: Re: [pgadmin-support] Is earlier error "Could not
> locate the record for deletion" fixed?
>
>
> Hi Dave,
>
> Sorry to bother you directly, but I need to know a bit more here :-)
>
> What I see is that this fails for tables containing fields of
> type "timestamp" Then the initial SQL request to the database
> from pgAdmin is:
>
> SELECT count(*) AS count FROM "productorder" WHERE
> "date" = '2002-03-01 09:14:42' AND "customerid" = '13325'
>
> Then the "date" field is of type timestamp.
> This one works however:
>
> SELECT count(*) AS count FROM "productorder" WHERE
> "date" = '2002-03-01 09:14:42.33+01' and "customerid" = '13325'

Hi,

Yes, this is one of the problems. In PostgreSQL 7.2, the precision of
timestamps was increased to 6 digits left of the seconds (2002-06-12
08:16:39.832925+01). Somewhere in ODBC/ADO this gets rounded to 2 places
which is technically a different value. Similar things can happen with
the timezone as you have found.

The latest dev code ignores such columns altogether, and will use only
the primary key for record location if one exists. If not, it just
builds the best WHERE clause it can.

Regards, Dave.

Browse pgadmin-hackers by date

  From Date Subject
Next Message Vergoz Michael 2002-06-12 09:47:03 SPI
Previous Message Dave Page 2002-06-12 07:05:13 Re: Patch file for table drop on import