Dave, your suggestion worked ... creating a new database, and a new table
within it made it possible to edit the table without error. For
completeness, the new table definition appears below, but it's pretty clear
that there's no meaningful difference between it and the one that didn't
work:
CREATE TABLE "TestTable"
( "keyColumn" int8 NOT NULL DEFAULT
nextval('"TestTable_keyColumn_seq"'::regclass), "myDataColumn" varchar(30), CONSTRAINT "TestTable_pkey" PRIMARY KEY
("keyColumn")
)
WITHOUT OIDS;
ALTER TABLE "TestTable" OWNER TO postgres;
Based on this result I went back to the original database, created a new
table with an identical definition, and tried to edit the new table. It
worked just fine.
One pattern that suggests itself is that the troublesome tables were ones
for which I had changed the schema, by deleting the primary key column and
adding a new one. The tables were empty when I did this, so I didn't think
that it would be a problem.
I guess that the old idea in database engineering of doing the work to get
the schema right the first time around really applies in this case :) .
Thanks much,
Dave Nash
>> Hmm, OK. If you recreate that table in a scratch database do you then
>> get the same error when editting, or is the problem confined to the
>> original tables?
>> ...
>> Regards, Dave.
