When you designate a column as the primary key in SQL Server Management Studio, it automatically creates a clustered index on the column. How do you replace the index with a non-clustered one using the SQL Server Management Studio user interface, but without generating or writing a script to drop the index and create the non-clustered one?
I know how to do it with a script (ALTER TABLE and then DROP CONSTRAINT), whether hand-written or generated using Management Studio. I am asking how to do it using only the Management Studio user interface. Because I remember I did it in the past. Only, I've forgotten how to do it because it has been a few months now.
I am using SQL Server Management Studio v17.9.1.
Alright, with some more poking around, I found out what I had done earlier. This is the way.
Right-click on the primary key column when it is open in the designer and select the menu command Indexes/Keys.
Set Create as Clustered to the value No in the ensuing dialog.
See the pictures below.
Related
I could change the index property in one of the table from Unique, Non-Clustered, Filtered to Non-Unique, Non-Clustered in SQL Server on local machine. But I could NOT find any property in accessing Azure SQL Database via SQL Server MAnagement Studio.
How do I change in via TSQL?
After upgrading to latest SSMS 17.9.1, still not be able to change this via this tool So the query will drop first and then recreated:
DROP INDEX [IX_ClubApplicationUser_LastModifiedBy] ON [dbo].[ClubApplicationUser]
GO
CREATE NONCLUSTERED INDEX [IX_ClubApplicationUser_LastModifiedBy] ON [dbo].[ClubApplicationUser]
(
[LastModifiedBy] ASC
)
GO
This will change into NONCLUSTERED, NON-UNIQUE as well as NON-FILTERED.
The reason we change as the "Code First" approach in .NET CORE 2 generated automatically this type of index.
I'm following a course on edX and I'm using the AdventureWorksLT database for the exercises, everything seems fine.
However, in the Object Explorer I can't see the attributes (columns) of a table.
When I expand the table I see 4 subfolders:
Keys (which generates an error when I try to open it)
Constraints
Triggers
Statistics
No attributes/columns of the table.
Does anyone know how to fix this? I really need this sometimes to see, for instance, the type of attribute (i.e. varchar or int).
The database is hosted on Microsoft Azure and I'm using SQL Server 2014 Management Studio and database.
I tried everything. With a Local File is working and I had to install a instance of SQL Server in my local machine and is also working but when I change my connection string to the SQL Azure doesn't work. I'm testing the same user and password in the Server Explorer inside of my Visual Studio where my application is and works. I don't know what else to do.
I spent the better part of the day trying to figure it out. The problem is that SQL Azure requires clustered indexes on your tables. The example SQL code provided by log4net (http://logging.apache.org/) and 99% of the tutorials on the internet, are to create the Log table does not have a clustered index, which is a requirement for SQL Azure. Adding any data at all to the table will fail unless it has a clustered index.
Try doing a manual insert statement using SQL Server Management Studio while connected to SQL Azure and it will tell you straight away if this is the problem. If so, run the following SQL to add a clustered index on the table (assuming you used the SQL direct from log4net) and then try again.
CREATE UNIQUE CLUSTERED INDEX PK_Log ON [Log]
([Id])
GO
In Visual Studio Database Projects I've seen table constraints being added in 2 different ways:
As part of the same script file used to create the table, after the CREATE TABLE statement;
In a separate file, kept in a "Tables\Constraints" folder, one constraint per file.
Are there good reasons to do one or the other?
Visual Studio does number 2 when importing a database from SQL Server, so I would guess that's the best way, but I can't see why. From a developer point of view number 1 seems better, as it keeps the table definition and constraints "closer" to each other.
I can only think of reasons to keep them together (#1) for exactly the reasons you mentioned: it keeps the table definition and constraints closer to each other.
Visual Studio used to keep constraints in separate files but stopped that practice in the latest "SQL Server Database Project" template introduced by SQL Server Data Tools (installed in VS 2012 out of the box, and requires a separate download for VS 2010).
Strong vote for #1. Separating the constraints from the table scripts makes it a real pain to add non-nullable columns later. When you deploy, the generated ALTER TABLE script will not be able to add a NOT NULL column to a table with existing data, because it doesn't have a DEFAULT constraint. If the constraint is already in the CREATE TABLE script, the ALTER TABLE will use it and everything will just work.
I've been using SQL Server for years, so I'm not a noob. I've recently been having problems where I can't add a foreign key to certain tables in my database using SQL Management Studio and SQL Server 2008 Express. The table I'm trying to reference is there and it has a primary key (with the primary key constraint created), but it doesn't show up in the list of tables that I can choose from when I'm trying to add the FK.
If I try and add the FK through plain old T-SQL, the query succeeds, but if I view the new FK using the UI, the primary key table dropdown is empty. The FK is there and it actually does work if I try to insert some data that would violate the constraint.
Anyone know why this would be happening?
This sounds like a tool issue (SSMS), not an engine issue
Thoughts:
close/reopen SSMS (caching?)
patched to same version as server install?
different schema etc?
Edit, after comment and it's SSMS caching:
You can also right-click on the table node and refresh so SSMS updates the cache. This problem goes back to SQL Enterprise Manager and SQL 2000. No known fix after 10 years...