Weird situation here. I'm inserting a row in a table with a primary key with IDENTITY (1,1), but the value that it uses is waaay wrong. This is the table:
CREATE TABLE [dbo].[adm_tm_modulo](
[id_modulo] [int] IDENTITY(1,1) NOT NULL,
[codigo] [varchar](255) NULL,
[descripcion] [varchar](255) NULL,
[estado] [int] NOT NULL,
[fecha_actualizacion] [datetime2](7) NULL,
[fecha_creacion] [datetime2](7) NULL,
[id_usuario_actualizacion] [int] NOT NULL,
[id_usuario_creacion] [int] NOT NULL,
[nombre] [varchar](255) NULL,
[ruta] [varchar](255) NULL,
PRIMARY KEY CLUSTERED
(
[id_modulo] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
GO
Right now, it has 4 rows as you can see:
But whenever I insert a new row, the primary key ends up as if the IDENTITY value starts at 1000. This is what happens after I execute the INSERT:
I am certain that I have never inserted that many rows before, nor anyone else as this is a private DB in my own PC. Also, adding all the rows of all the tables, they are around 400 (not even close to 1000). And I tried inserting in other tables but the same thing is happening, only that in some tables it inserts a value from 3001 foward, or 4001, etc. It always starts with the first number after a thousand.
Any help about why this is happening would be very appreciated.
You may want to use a SEQUENCE object, which gives you more control on behavior of values generating.
https://learn.microsoft.com/en-us/sql/t-sql/statements/create-sequence-transact-sql?view=sql-server-ver15
Another option (which I prefer better) is to create an INSERT TRIGGER and define the logic you want in it
Related
I have a SQL Server table linked in an Access app. If I try to delete records with a delete query there is no problem. But if I try to delete records directly in table or using a select query in datasheet mode Access doesn't allow me to delete the records and throws the following warning:
"The microsoft access database engine stopped the process because you and another user are attempting to change the same data at the same time."
The same happens when I try to update data. There is no other user modifying the data.
The problem is that we still have a lot of legacy forms that uses datasheet mode to alter o delete records instead of using queryes and, for now, changing all these forms is unthinkable.
¿Has anyone any idea of what could be happening?
Thanks!
FINAL EDIT:
The problem was a bit field that was set to nullable that, thanks to Kostas K. I discovered is not convertable to Access.
So, instead of this:
[FIELD] [bit] NULL
We need tis:
[FIELD] [bit] NOT NULL
ALTER TABLE [dbo].[TABLE] ADD DEFAULT ((0)) FOR [FIELD] GO
UPDATE: This locking only happens with new records added from Access, but not with the original records of the SQL table.
This is the script to create the table:
`
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [Chapas].[INFO_CHAPAS](
[ID_INFO_CHAPA] [int] IDENTITY(1,1) NOT NULL,
[COD_EQUIPO] [int] NULL,
[EQUIPO] [nvarchar](255) NULL,
[NUMERO_SERIE] [nvarchar](255) NULL,
[FASES] [nvarchar](255) NULL,
[VOLTAJE] [nvarchar](255) NULL,
[FRECUENCIA] [nvarchar](255) NULL,
[POTENCIA] [nvarchar](255) NULL,
[AÑO] [int] NULL,
[IMPRESO] [bit] NULL,
[SELECTOR_REGISTRO] [bit] NULL,
[USUARIO] [int] NULL,
[FECHA_IMPRESION] datetime NULL
CONSTRAINT [INFO_CHAPAS_PK] PRIMARY KEY NONCLUSTERED
(
[ID_INFO_CHAPA] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY
= OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
ALTER TABLE [Chapas].[INFO_CHAPAS] ADD DEFAULT ((0)) FOR [IMPRESO]
GO
`
Before anyone says this is a duplicate question and down-votes: I know how to solve the issue but I would like the advice on which is the best way to go about it.
I have made a booking system, where employees can create bookings. The employees table has a primary key of their clock number, this is a foreign key in the bookings table because employees can only delete their own bookings unless they are an administrator.
Now the problem occurs when I want to remove an employee, but they have made 1 or more bookings in the system, obviously as I'm deleting the 'parent' the 'child' will want to be removed as well but I need to keep the entire history of bookings.
The solutions I have is to remove the foreign key constraint in the bookings table, so there is still a clock number but not a foreign key. Or to set something up with ON CASCADE NULL feature?
CREATE TABLE [dbo].[Employees](
[ClockNo] [int] NOT NULL,
[Forename] [varchar](20) NOT NULL,
[Surname] [varchar](20) NOT NULL,
[Email] [varchar](50) NOT NULL,
[Department] [varchar](50) NOT NULL,
[IsAdmin] [bit] NOT NULL,
[Password] [varchar](max) NOT NULL,
CONSTRAINT [PK_Employees] PRIMARY KEY CLUSTERED
(
[ClockNo] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
CREATE TABLE [dbo].[Bookings](
[InvoiceNo] [varchar](40) NOT NULL,
[ClockNo] [int] NOT NULL,
[GateNo] [smallint] NOT NULL,
[TruckNo] [smallint] NOT NULL,
[StartTime] [datetime] NOT NULL,
[EndTime] [datetime] NOT NULL,
[Status] [varchar](20) NOT NULL,
[Seal] [varchar](40) NULL,
[ContainerNo] [varchar](40) NULL,
CONSTRAINT [PK_Bookings] PRIMARY KEY CLUSTERED
(
[InvoiceNo] ASC,
[GateNo] ASC,
[StartTime] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
If there is a way without doing any of these things that would be great, as I would like the clock number to stay even if the employee has been removed so we can see who had made the booking, even if they no longer work for us
Best approach would be to have a flag in the Employee table as isDeleted and use that flag to maintain deleted employees. That way you will have records of all the orders of the deleted employees as well
This question already has answers here:
Adding an identity to an existing column
(19 answers)
Closed 8 years ago.
I have created a SQL Server database table but forgot to set auto increment in the primary key column. How can I set the auto increment to the existing primary key field?
CREATE TABLE [dbo].[STUDENT_INFO]
(
[ROLLNO] [INT] IDENTITY(1, 1) NOT NULL,
[SCHOOLID] [INT] NOT NULL,
[STUDENTID] [INT] NOT NULL,
[NAME] [NVARCHAR](50) NOT NULL,
[AGE] [INT] NOT NULL,
[GENDER] [NVARCHAR](10) NOT NULL,
[ADDRESS] [NVARCHAR](500) NULL,
[CONTACTNO] [NVARCHAR](20) NOT NULL,
[EMAIL] [NVARCHAR](50) NULL,
[ISACTIVE] [BIT] NOT NULL,
[INSTRUMENTID] [INT] NOT NULL,
[GRADEID] [INT] NOT NULL,
[DISCOUNT] [INT] NOT NULL,
[STARTTIME] [TIME](7) NOT NULL,
[DURATION] [TIME](7) NOT NULL,
PRIMARY KEY CLUSTERED ( [STUDENTID] ASC ) WITH (PAD_INDEX = OFF,
STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
)
ON [PRIMARY]
I am working with SQL Server Management Studio 2012.
I was about to say that it can't be done. That you have to drop and recreate the primary key (or, just create the entire table from scratch, move the data over, and drop the old table).
EDIT:
But depending on your version and edition of SQL Server, you may be able to use the object explorer to navigate to the table and access its design properties there. Where you can then set the column to an identity type.
However as someone pointed out, it may actually drop and recreate the table anyway in the background.
Anyway, as the OP already contains an edit to an answer the same as what I suggested at first (replacing the PK with another one, or recreating the table and moving the data there), I suppose there's no need to go further into this.
I created a table manually and after that selected script table as new query and changed table name and executed the query. I am getting the error as
Msg 170, Level 15, State 1, Line 12 Line 12: Incorrect syntax near
'('.
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE dbo.[KitCodeProperties](
[KitPropertiesId] [int] IDENTITY(1,1) NOT NULL,
[KitCodeName] [varchar](50) NULL,
[KitCodeDescription] [varchar](200) NULL,
[ShippingInstructions] [varchar](200) NULL,
[DepartmentId] [int] NULL,
[KitCodeActive] [bit] NULL,
CONSTRAINT [PK_KitCodeProperties] PRIMARY KEY CLUSTERED
(
[KitPropertiesId] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF,
ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
SET ANSI_PADDING OFF
GO
I took you code and pasted it into my 2012 developer edition. Had no issues creating the table with and without SET commands.
Therefore, the syntax looks good.
Are you selecting on a section of the window?
Make sure you are not selection anything in the new query window and press F5 to execute the whole window as one batch.
If this works, you were highlighting only a section of the code.
A simplified version of the SSMS code.
-- Remove old existing table
IF OBJECT_ID('[dbo].[KitCodeProperties]') > 0
DROP TABLE [dbo].[KitCodeProperties];
-- Create new table
CREATE TABLE [dbo].[KitCodeProperties]
(
[KitPropertiesId] [int] IDENTITY(1,1) NOT NULL PRIMARY KEY CLUSTERED,
[KitCodeName] [varchar](50) NULL,
[KitCodeDescription] [varchar](200) NULL,
[ShippingInstructions] [varchar](200) NULL,
[DepartmentId] [int] NULL,
[KitCodeActive] [bit] NULL,
);
The cut down version works fine in SQL Fiddler.
I have a table in a database with 580 million rows in it, and an awkward composite primary key. I would like to change the structure of the table to have an identity column as the primary key.
I am looking for some suggestions on the best possible way of doing this in the shortest amount of time.
We are using SQLServer 2008.
Current table structure:
CREATE TABLE [dbo].[POINTS_EARNED](
[CARD_ID] [int] NOT NULL,
[CYCLE_ID] [int] NOT NULL,
[POINTS_CODE] [int] NOT NULL,
[NO_POINTS] [int] NULL,
[ACCOUNT_ID] [int] NOT NULL,
[CREATED_DATE] [datetime] NULL,
[CREATED_BY] [varchar](20) NULL,
[LAST_MODIFIED_DATE] [datetime] NULL,
[LAST_MODIFIED_BY] [varchar](20) NULL,
[DELETED] [bit] NULL,
CONSTRAINT [PK_POINTS_EARNED] PRIMARY KEY CLUSTERED
(
[CARD_ID] ASC,
[CYCLE_ID] ASC,
[POINTS_CODE] ASC,
[ACCOUNT_ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
) ON [PRIMARY]
New structure
CREATE TABLE [dbo].[POINTS_EARNED](
[Points_EARNED_ID] [int] [Identity] Primary Key,
[CARD_ID] [int] NOT NULL,
[CYCLE_ID] [int] NOT NULL,
[POINTS_CODE] [int] NOT NULL,
[NO_POINTS] [int] NULL,
[ACCOUNT_ID] [int] NOT NULL,
[CREATED_DATE] [datetime] NULL,
[CREATED_BY] [varchar](20) NULL,
[LAST_MODIFIED_DATE] [datetime] NULL,
[LAST_MODIFIED_BY] [varchar](20) NULL,
[DELETED] [bit] NULL
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]
) ON [PRIMARY]
In the past we have tried 2 ways of doing this on other tables that needed to be restructured:
Create an empty table in the new structure
INSERT INTO
Newtable SELECT * FROM Oldtable
rename old table oldtable_bak
rename new table as old table
Add indexes, etc to new table
Unfortunately, with large tables this tends to cause SSMS to crash, so we have copied the data by changing step 2 to be:
bcp data out of the old table into a text file, and then bcp it back into the new table from the text file, which seems to work, but it takes several hours.
I'm interested to know whether there is a better, more efficient way of doing this.
I'm not sure if it is more efficient, but the following is "better" in a certain sense:
Insert existing data into a new table
Truncate existing table
Alter table to had identity primary key
Insert into new table
The reason this is better is because it preserves triggers, constraints, permissions, and other references to the table. That can be quite handy many applications.
As your implicitly point out, you might want to remove all indexes from the original table and add them after the data is re-inserted. Generally, building indexes all at once is more efficient.