Re: ERROR: Could not locate the record for dele

> -----Original Message-----
> From: Dario Scopesi [mailto:dario(at)ventia(dot)com]
> Sent: 06 November 2001 21:33
> To: pgadmin-support(at)postgresql(dot)org
> Subject: [pgadmin-support] ERROR: Could not locate the record
> for deletion in the database!
>
>
> (pgAdmin2, 1.1.59)
>
> When I try to delete a record from a table/view data (select
> the record, press delete button), this error message is
> shown: "Could not locate the record for deletion in the database!"
>
> This is the table definition:
> CREATE TABLE "partners" (
> "id" int8 NOT NULL,
> "firstname" text NOT NULL,
> "lastname" text NOT NULL,
> "company" text,
> "username" text NOT NULL,
> "country" text NOT NULL,
> "state" text,
> "hear" text,
> "regdate" timestamp NOT NULL,
> "email" text NOT NULL,
> CONSTRAINT "partners_pkey" PRIMARY KEY ("id")
> );
>
> and this is the log (level: debug)
> 07/11/2001 8:21:10 AM - Counting matching records...
> 07/11/2001 8:21:10 AM - SQL (desknow): SELECT count(*) AS
> count FROM "partners" WHERE "id" = '119706' AND "firstname" =
> 'Dario' AND "lastname" = 'gva' AND "company" = 'company' AND
> "username" = 'dtest4' AND "country" = 'country' AND "state" =
> 'state' AND "hear" = 'hear' AND "regdate" = '2001-10-20
> 18:16:01' AND "email" = 'dario(at)nowhere(dot)com' 07/11/2001
> 8:21:10 AM - Done - 0.37 Secs.
>
> Looks like it can't find the record (btw, being a primary key
> there, wouldn't it be easier to limit the WHERE clause to
> it?) Has it anything to do with 'text' type fields?

Hi Dario,

I've been working on this code recently and fixed a couple of bugs that
cause this problem. I hope to package a build this week if you can wait for
that to test...

Historically, the code that does this is about the only code that was lifted
almost verbatim from the old pgAdmin code. It relies on Microsoft ADO & ODBC
to provide information such as pkeys about the resultset which unfortunately
is not reliable. In order to overcome this, I had 2 choices:

1) Try to match all columns in the SQL (which I opted for). This gives the
advantage that multiple rows can be updated or deleted if required (ADO just
throws an error if this would happen).

2) Parse the SQL query and try to figure out what the result set will look
like. This is *horrendously* complex to do and is best left to the
PostgreSQL backend.

HTH, Regards, Dave.