I have a previously created table and I am trying to make the Primary Key, which is BookingID, auto increment. I have 4 records in the database currently. The SQL function keeps telling me there is a syntax error near ' ALTER' . I am using SQLite if that matters.
ALTER TABLE Booking AUTO_INCREMENT=5
Because "alter" in SQLite only lets you rename tables or add columns; it doesn't support what you're trying to do.
For more information, check out the documentation of ALTER TABLE in SQLite:
SQLite supports a limited subset of ALTER TABLE. The ALTER TABLE command in SQLite allows the user to rename a table or to add a new column to an existing table.
Related
I was quite confused on why in the preperation for the microsoft 70-461 exam it says this:
Create tables without using the built in tools; ALTER; DROP; ALTER COLUMN; CREATE
What exactly does ALTER COLUMN mean? I do not recall that being a statement or command could anybody please explain this for me. Thanks :)
You use it as part of an alter table statement to change a column definition:
alter table t1
alter column c1 varchar(50) not null
It will give an error without the alter table piece.
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 created a new table, without auto increment of the primary key and inserted set of predefined data's into the table. Now I need to set the auto increment for the primary key, which I'm not able to set. please suggest the mistake i have done in the query below.
ALTER TABLE SYNCBASE.AUTO_LOAD_DATASOURCES
ALTER COLUMN ID BIGINT NOT NULL PRIMARY KEY GENERATED ALWAYS AS IDENTITY (START WITH 62, INCREMENT BY 1)
Till 61 rows i have inserted the records, it has to increment from 62 onwards. but i;m getting error as
Error: DB2 SQL Error: SQLCODE=-104, SQLSTATE=42601, SQLERRMC=BIGINT;RCES
ALTER COLUMN ID;SET, DRIVER=3.53.95
SQLState: 42601
ErrorCode: -104
Thanks in advance
The issue might be coming from the fact that you already have data in your database and modifying the primary key would violate the data integrity. Or you may check whether your DBMS allows you to make changes to a table after creating it.
first of all... we need to drop the identity and then alter the column, only then it works.
alter table SYNCBASE.AUTO_LOAD_DATASOURCES alter column ID drop identity;
alter table SYNCBASE.AUTO_LOAD_DATASOURCES alter column ID set generated always as identity (start with 62, INCREMENT BY 1);
There is a syntax error in the DDL statement. The column definition doesn't need to be repeated. This statement will work:
ALTER TABLE SYNCBASE.AUTO_LOAD_DATASOURCES
ALTER COLUMN ID SET GENERATED ALWAYS AS IDENTITY (START WITH 62);
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 have a table and I want to drop or set the default value of one of columns. I use below scripts :
ALTER TABLE AccAccountGroup ALTER COLUMN Name DROP DEFAULT
ALTER TABLE AccAccountGroup ALTER COLUMN Name SET DEFAULT 'default value'
when I run the scripts, below errors appears :
Incorrect syntax near the keyword 'DEFAULT'. => for drop script
Incorrect syntax near the keyword 'SET'. => for add script
these scripts are from msdn.
What is the problem? I use SQL Server 2008 R2.
I believe that your reference is for SQL Server Compact Edition. Use this one instead.
You need to use the CONSTRAINT syntax and you need to use the default's name. Even though you didn't assign a name (and I suggest that you do in the future as it's a good practice), SQL Server will assign one, which you can find using EXEC sp_help AccAccountGroup.
Try these syntaxes:
ALTER TABLE AccAccountGroup
DROP CONSTRAINT <default name>
ALTER TABLE AccAccountGroup
ADD CONSTRAINT DF_AccAccountGroup_name DEFAULT 'default value' FOR name
The link you provided refers only to SQL Server Compact Edition, not the 'full' SQL Server. The above statements are only valid in SQL Server Compact Edition.
In the 'full' SQL Server, default values for columns are implemented using constraints. You can add a default constraint to a table using something like
ALTER TABLE AccAccountGroup ADD CONSTRAINT AccAcctGrp_Name_Def DEFAULT 'default value' FOR name;
and drop it using
ALTER TABLE AccAccountGroup DROP CONSTRAINT AccAcctGrp_Name_Def;
Note that you need to provide the name of the constraint when you drop it. If you don't know the name of the constraint, the following query will look it up. Change the schema name dbo, and also the table and column names, if/as necessary:
SELECT object_name(default_object_id)
FROM sys.columns
WHERE object_id = object_id('dbo.AccAccountGroup')
AND name = 'Name';
Once you've got the name of the constraint, you can drop it. (Acknowledgement: this query was taken from a comment posted here.)