I run the following 2 statements in order:

ALTER TABLE People
ADD COLUMN "XID" INTEGER GENERATED BY DEFAULT AS IDENTITY (START WITH 1, INCREMENT BY 1) NOT NULL

ALTER TABLE "People"
DROP CONSTRAINT "PK_People",
DROP COLUMN ID,
RENAME COLUMN XID TO ID,
ADD CONSTRAINT "PK_People" PRIMARY KEY ("ID"),
ALTER COLUMN ID MOVE TO 1,
ALTER COLUMN ID AS INTEGER DEFAULT UID() NOT NULL

I am basically replacing 1 primary key field with another & cleaning up some things at the same time.

I would expect the above:

RENAME COLUMN XID TO ID,

to result in XID ceasing to be present on the table. However after I run it, I have an ID field and the XID field remains.

... not a big problem ... but not really EDB working as I would expect. I just have to add a DROP COLUMN XID statement to the SQL.

Is this part of a SQL standard, or something else?

Adam


1. I'd agree with your assumption (haven't tested it though)
2. Which version of ElevateDB (it may be version specific)
3. I'd report this direct to Tim via EMail

Roy Lambert [Team Elevate]

Adam,

<< Is this part of a SQL standard, or something else? >>

It's probably a bug, but it may be fixed also if you're using an older
version/build.

--
Tim Young
Elevate Software
www.elevatesoft.com

>><< Is this part of a SQL standard, or something else? >>

>>It's probably a bug, but it may be fixed also if you're using an older
>>version/build.

YUP. I was on build 6. (I think!)