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

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 (view raw or flat)
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.

pgadmin-hackers by date

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

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