Tag Info

New answers tagged

4

Another reason why you should use CONSTRAINTs instead of some inside-application-code: What happens if a developer / dba use an insert / update / delete statement to modify the data direct in the DB? In this case all your nice application based referential integrity will be useless. I know, some devs like the possibility to modify data direct without ...


7

First off, gaps in a sequence are to be expected. Ask yourself if you really need to remove them. Your life gets simpler if you just live with it. To get gap-less numbers, the (often better) alternative is to use a VIEW with row_number(). Example in this related answer: Gap-less sequence where multiple transactions with multiple tables are involved Here ...


0

Whist there were a number of useful comments and answers as mentioned in a previous comment of mine the problem was caused a rougue entry which would have corresoned to a PK of zero!. Deleting this solved the problem... How it got there is the issue...


0

Assuming you have no references to fred elsewhere, this may be the 'safe' way: ALTER TABLE bill DROP COLUMN fred, ADD COLUMN fred INT AUTO_INCREMENT NOT NULL PRIMARY KEY;


2

Your post intrigued me. There is a "workaround" here, but I was curious, so I performed the following tests. You might like to try what worked for me below before trying the workaround. If there are FOREIGN KEYs, and potential conflicts (duplicates and/or KEY violations), then this won't work. It may be the reason for your error. I created a table (bill) as ...


0

Right now, both your unique index and PK uniquely identify each row. This is redundant. The index can be remove and the cluster can be move into the PK. However it will fail if there are foreign keys on ItemId. First look for foreign key(s): Select OBJECT_NAME(constraint_object_id) From sys.foreign_key_columns where referenced_object_id = ...


3

The other two answers are spot on in that the reason why the two indexes exist: you told the database to create two indexes. Furthermore you could make your primary key clustered and remove the second index. To answer your question about why the second index is "needed" boils down to a limitation/requirement for Sql Server Azure edition databases that ...



Top 50 recent answers are included