Tag Info

New answers tagged

0

Try temporary disabling foreign keys (make sure no ones allowed to update the db meanwhile): create table t1 (id int not null primary key) engine = innodb; create table t2 (id int not null primary key ,t1_id int not null , constraint abc foreign key (t1_id) references t1 (id) ) engine ...


2

You can use the following MSDN_DBCC CHECKIDENT Hope that helps! DBCC CHECKIDENT (Transact-SQL) You can use DBCC CHECKIDENT to manually set a new current identity value for the identity column. DBCC CHECKIDENT ( table_name [, { NORESEED | { RESEED [, new_reseed_value ] } } ] ) [ WITH NO_INFOMSGS ] Example USE AdventureWorks2012; ...


6

You can use DBCC CHECKIDENT to reseed the IDENTITY column. Here is a sample you can run: SET NOCOUNT ON; USE tempdb; GO CREATE TABLE dbo.foo(ID INT IDENTITY(1,1)); GO INSERT dbo.foo DEFAULT VALUES; GO 100 -- note: set it to ([the next value you want] - 1) DBCC CHECKIDENT(N'dbo.foo', RESEED, 499); GO INSERT dbo.foo DEFAULT VALUES; GO 3 SELECT ID FROM ...


0

what would be the pros and cons of either using bigint or writing our own code which will assign IDs (in a way which reuses the IDs of already deleted records, to ensure there are no gaps)? Using bigint as an identity and living with the gaps: it's all in-built functionality you can be sure it will work out-of-the-box it will waste space since int ...


0

If I was your boss I would be most interested in the reasons for the unexpectedly high Id values... the way I see it, for each of the two scenarios you outlined: IF prior testing has bumped-up identity values - then your other comments about expected numbers of records would also push me to suggest a smaller key type. Frankly I'd also consider if it was ...



Top 50 recent answers are included