The SQL for the creation of the table is:
CREATE TABLE myTable(id INTEGER NOT NULL PRIMARY KEY, ...)
Instead I need it to be:
CREATE TABLE myTable(id INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1), ...)
as described in the Derby documentation. So my question is what would be the alter statement I would need to create AFTER the initial create statement? In other words:
CREATE TABLE myTable(id INTEGER NOT NULL PRIMARY KEY, ...)
ALTER TABLE myTable ...
Thank you very much for the assistance!
Looking at the documentation this seems impossible. You can change the type length (not even the type itself), the default, nullability and the next generated value but even the last option requires the column to already be defined as IDENTITY. A thread from 2009 says that you can't even add an IDENTITY column. A test confirms this is true to this day.
So it seems there is only one solution: You have to replace the table. Something like this:
create a new table with a placeholder name that contains the desired columns
copy any data over from the original table
drop the original table
rename the new table
It's really an unfortunate solution because if you already have other tables referencing the id column of your table as that would mean further work.
I tried messing with the system tables but they seem to be read-only (and for good reason).
Looks like this issue in Derby has been fixed as of the 10.12.1.1 release. Now commands such as:
ALTER TABLE t ADD COLUMN x INT PRIMARY KEY GENERATED ALWAYS AS IDENTITY
to an existing database now work, as does GENERATED BY DEFAULT. Looks like the change requires the underlying database to be at least in 10.11 format.
One technique is to: (a) create a new table with the new column defined as you desire, and all other columns as they were before, (b) run an INSERT INTO ... SELECT ... statement to copy all the data from the existing table to the new table, (c) RENAME TABLE to rename the old table to some other name, (d) RENAME TABLE to rename the new table to the correct tablename, and then finally (e) DROP TABLE the old table.
Related
When I try to change the data type of a column in a table by alter command...
alter table temp alter column id type bigserial;
I get
ERROR: type "bigserial" does not exist
How can I change the datatype from bigint to bigserial?
As explained in the documentation, SERIAL is not a datatype, but a shortcut for a collection of other commands.
So while you can't change it simply by altering the type, you can achieve the same effect by running these other commands yourself:
CREATE SEQUENCE temp_id_seq;
ALTER TABLE temp ALTER COLUMN id SET NOT NULL;
ALTER TABLE temp ALTER COLUMN id SET DEFAULT nextval('temp_id_seq');
ALTER SEQUENCE temp_id_seq OWNED BY temp.id;
Altering the owner will ensure that the sequence is removed if the table/column is dropped. It will also give you the expected behaviour in the pg_get_serial_sequence() function.
Sticking to the tablename_columnname_seq naming convention is necessary to convince some tools like pgAdmin to report this column type as BIGSERIAL. Note that psql and pg_dump will always show the underlying definition, even if the column was initially declared as a SERIAL type.
As of Postgres 10, you also have the option of using an SQL standard identity column, which handles all of this invisibly, and which you can easily add to an existing table:
ALTER TABLE temp ALTER COLUMN id
ADD GENERATED BY DEFAULT AS IDENTITY
ALTERing a column from BIGINTEGER to BIGSERIAL in order to make it auto-increment won't work. BIGSERIAL is not a true type, it is a trick that automates PK and SEQUENCE creation.
Instead you can create a sequence yourself, then assign it as the default for a column:
CREATE SEQUENCE "YOURSCHEMA"."SEQNAME";
ALTER TABLE "YOURSCHEMA"."TABLENAME"
ALTER COLUMN "COLUMNNAME" SET DEFAULT nextval('"YOURSCHEMA"."SEQNAME"'::regclass);
ALTER TABLE "YOURSCHEMA"."TABLENAME" ADD CONSTRAINT pk PRIMARY KEY ("COLUMNNAME");
This is a simple workaround:
ALTER TABLE table_name drop column column_name, add column column_name bigserial;
Sounds like alot of professionals out there on this subject... if the original table did indeed have data then the real answer to this dilemma is to have designed the db correctly in the first place. However, that being the case, to change the column rule (type) would require integrity verification of that column for the new paradigm. And, don't forget, anywhere where that column is manipulated (added/updated) then that would need to be looked into.
If it's a new table then okay, simples: delete column and re-add new column (takes care of the sequence for you). Again, design, design, design.
I think we've all fouled on this.
I have an old existing interbase table and I want to add a primary key field to and populate it. Is there any way to do it all in the SQL statement (like SQL server). Example:
ALTER TABLE IBUSERS ADD IBUSERSPK VARCHAR(32) default (newid()) NOT NULL
As far as I can tell in interbase newid function does not exist unless I am missing something.
I am using IBExpert and also have IBConsole.
Or am I stuck with populating this field in code after it gets created?
Thanks.
It appears interbase has no easy way to SQL populate a guid field. Therefore the solution is to create your own UDF function in the database to create a random guid. It then becomes a three step process:
Add the field to the table
ALTER TABLE IBUSERS ADD IBUSERSPK VARCHAR(32) NOT NULL
Populate the new field using the UDF:
UPDATE IBUSERS SET IBUSERSPK = GETGUID()
Add primary key constraint if it is such:
ALTER TABLE IBUSERS ADD CONSTRAINT PK_IBUSERS PRIMARY KEY (IBUSERSPK)
The nice thing about this is that then this function can be used anytime/anywhere in the database.
I'm trying to add a new column to my exiting table but I keep getting an error trying to insert non-null columns.
I understand how this would be an issue to existing databases with lots of data, but my database has no data yet so I'm confused as to why I'm getting this error.
Is there an easy solution for this (I don't want to add default values)
You've got two options, feed it a default value, or add the field without the non-null constraint, then alter the table later to add the non-null constraint after you've populated the field.
This works fine when the table is empty.
CREATE TABLE X(Y INT)
ALTER TABLE T ADD Y INT NOT NULL
There is no need to add a temporary default constraint or create it as NULL, populate then ALTER except if the table is, in fact, not empty as claimed.
I don't think that table is as empty as you think it is.
Try this:
Truncate Table <YourTableName>
Then try the alter table statement.
I am using Netbeans, writing in Java and using Derby.
I have a table within APP called PERSON. Within PERSON I have a column called PID with the following properties:
Name: PID
Nulls allowed: [ ]
Data type: NUMERIC
Column size: 4
Decimal digits: 0
Position: 1
Part of a primary key: [/]
Part of an index: [/]
I used the meta data isAutoIncrement function to check if it was already auto incrementing and it is not!
I have since tried using the following SQL commands to alter it:
I believe this may not have been for Derby:
ALTER TABLE APP.PERSON ALTER PID NOT NULL PRIMARY KEY GENERATED ALWAYS AS IDENTITY
(START WITH 1, INCREMENT BY 1);
Upon checking the Oracle website, I found the correct syntax:
ALTER TABLE APP.PERSON ALTER PID SET INCREMENT BY 1;
I even tried leading zeros:
ALTER TABLE APP.PERSON ALTER PID SET INCREMENT BY 0001;
None of which have worked, the error I get on the last two are:
ALTER TABLE '"APP"."PERSON"' specified attributes for column 'PID' that are
not compatible with the existing column.
Any ideas of the correct syntax?
Here's what I generally do to accomplish this:
Create a new table, with the desired schema, including the generated primary key
Issue a INSERT INTO newtable SELECT columns FROM oldtable to populate the new table's data from the old table
Rename the old table to some temporary name, like table_soon_to_be_deleted
Rename the new table to the desired table name
Do some testing to make sure that my behavior is as expected
Drop the old table that I renamed in step (4).
JavaDB does not allow altering a column with generated key word so I found the best way is to recreate the table and specify the primary key as auto incremented. For example;
create table staff(
ID int primary key always generated as identity,
name varchar(100)
);
This worked for me.
I have an existing table where I use existing column (type INT) as PK and manually increment its value with each row inserted. I wanted to change it to IDENTITY with auto increment. I found a thread here (http://stackoverflow.com/questions/4862385/sql-server-add-auto-increment-primary-key-to-existing-table) that seems to achieve exactly what I want. But every time I run the ALTER statement, Mgmt Studio crashes.
I had also tried to achieve my above goal by changing the column properties manually (Identity specification/Is Identity:yes) as in this thread (http://stackoverflow.com/questions/3876785/sql-server-cant-insert-null-into-primary-key-field). But every time I close the table after changing properties, I get an error
'Pix' table
Unable to modify table.
Cannot insert the value NULL into column 'picID', table 'photo.dbo.Tmp_Pix'; column does not allow nulls. INSERT fails.
The statement has been terminated.
Not sure what's going on.
You cannot change an existing column to become an IDENTITY column.
What you need to do is:
create a new column with INT IDENTITY
drop the primary key constraint
drop the old column
add the primary key constraint on the new column
The trouble might be - if you already have data in that table - that the new identity values don't necessarily match the old values in your manual ID column.
If you need to preserve those, then it gets even more involved:
create a new table with the proper structure, and make sure that the ID column is INT IDENTITY
turn on IDENTITY_INSERT for that table
insert all the rows from the old table into the new one (and in the process, insert the old ID values into the new ID IDENTITY column)
turn off IDENTITY_INSERT for that table
drop the old table
possibly rename the new table