Re: Serious bug in edit grid? - Mailing list pgadmin-support
From | Chris St Denis |
---|---|
Subject | Re: Serious bug in edit grid? |
Date | |
Msg-id | 006801c62094$ba845080$6401a8c0@chris Whole thread Raw |
In response to | Serious bug in edit grid? ("Chris St Denis" <Chris@ctgameinfo.com>) |
List | pgadmin-support |
Latest stable version of pgadminIII -- 1.4.1 postgresql 8.0.4 running on FreeBSD 5.4 (from ports) I do not belive I dropped and readded any columns to this table. customer_service_attribute_id should have been there as a serial from the start. --- Another unrelated bug I'll like to bring up. On connect as an admin with the extensions installed an error is generated regarding /proc/uptime because freebsd does not by default have a /proc. Workaround: install procfs or ignore. proper solution: supress the error or obtain uptime using another method. ----- Original Message ----- From: "Andreas Pflug" <pgadmin@pse-consulting.de> To: "Chris St Denis" <Chris@ctgameinfo.com> Cc: <pgadmin-support@postgresql.org> Sent: Monday, January 23, 2006 3:33 PM Subject: Re: [pgadmin-support] Serious bug in edit grid? > Chris St Denis wrote: > > > When editing my table contents multiple rows wiht the same value all > > get changed. > > > > Table design: > > > > CREATE TABLE customer_service_attributes > > ( > > customer_service_attribute_id int4 NOT NULL DEFAULT > > nextval('public.cust_srv_features_customer_service_attributes_seq'::text), > > _service_id int4 NOT NULL, -- This can be derrived from the attrib > > ID, but is also here to make queries easier. > > service_attr_id int4 NOT NULL, > > _customer_id int4 NOT NULL, > > customer_service_id int4 NOT NULL, > > value text NOT NULL, > > CONSTRAINT customer_service_attributes_pkey PRIMARY KEY > > (customer_service_attribute_id), > > CONSTRAINT customer_service_attributes_customer_id_fkey FOREIGN KEY > > (_customer_id) > > REFERENCES customer (customer_id) MATCH SIMPLE > > ON UPDATE RESTRICT ON DELETE RESTRICT, > > CONSTRAINT customer_service_attributes_customer_service_id_fkey > > FOREIGN KEY (customer_service_id) > > REFERENCES customer_services (customer_service_id) MATCH SIMPLE > > ON UPDATE RESTRICT ON DELETE RESTRICT, > > CONSTRAINT customer_service_attributes_service_attr_id_fkey FOREIGN > > KEY (service_attr_id) > > REFERENCES service_attribute (service_attr_id) MATCH SIMPLE > > ON UPDATE RESTRICT ON DELETE RESTRICT, > > CONSTRAINT customer_service_attributes_service_id_fkey FOREIGN KEY > > (_service_id) > > REFERENCES service (service_id) MATCH SIMPLE > > ON UPDATE RESTRICT ON DELETE RESTRICT > > ) > > WITHOUT OIDS; > > > > > > When editing the value feild in rows in the grid changing value x to > > y, all rows with value x become y. Looking in the query log shows the > > following > > > > STATEMENT: UPDATE customer_service_attributes SET > > value='y'::pg_catalog.text WHERE value = 'x'::pg_catalog.text > > > > Shouldn't this be refrencing the primary key of > > customer_service_attribute_id in the where clause? as in > > > > STATEMENT: UPDATE customer_service_attributes SET > > value='y'::pg_catalog.text WHERE customer_service_attribute_id = 620 > > > > > > Am I doing something wrong or is there a massive bug here?? > > > Which version? > We had a recent fix that could hit you when you dropped columns and > readded some as PK. > > Regards, > Andreas > >
pgadmin-support by date: