Why do I get message that the table needs to dropped and re-created when I add/move columns?
I believe this happens after adding foreign key constraints.
What can I do to add new columns without dropping table?
If you're more interested in simply getting SSMS to stop nagging, you can uncheck the "Prevent saving changes that require table re-creation" setting in Options->Designers->Table And Database Designers. The table(s) will still be dropped and re-created, but at least SSMS won't pester you quite as much about it.
(This assumes you're working in an dev/test environment or in a production environment where a brief lapse in the existence of the table won't screw anything up)
Because that's how SQL Server Management Studio does it (sometimes)!
Use TSQL's ALTER TABLE instead:
ALTER TABLE
ADD myCol int NOT NULL
SQL Server (and any other RDBMS, really) doesn't have any notion of "column order" - e.g. if you move columns around, the only way to achieve that new table structure is be issuing a new CREATE TABLE statement. You cannot order your columns any other way - nor should you, really, since in the relational theory, the order of the columns in a tuple is irrelevant.
So the only thing SQL Server Management Studio can do (and has done all along) is:
rename the old table
create the new table in your new layout you wish to have
copy the data over from the old table
drop the old table
The only way to get around this is:
not reordering any columns - only add new columns at the end of your table
use ALTER TABLE SQL statements instead of the interactive table designer for your work
When you edit a table definition in the designer, you are saying "here's what I want the table to look like, now work out what SQL statements to issue to make my wishes come true". This works fine for simple changes, but the software can't read your mind, and sometimes it will try to do things in a more complicated way for safety.
When this happens, I suggest that, instead of just clicking OK, click the "Script" button at the top of the dialog, and let it generate the SQL statements into a query window. You can then edit and simplify the generated code before executing it.
There are bugs in SSMS 2008 R2 (and older) that are useful to know:
when the table data is changed, ерушк rendering in SSMS is autorefreshed by SSMS in its already opened tabs (windows) - one should press Ctrl+R to refresh. The options to force refreshing do not appear in SSMS GUI - through buttons, menus or context-sensitive options (on right-clicking)
when a (table or database) schema is modified, like adding/deleting/removing a column in a table, SSMS does not reflect these changes in already opened tabs(windows) even through Ctrl+R, one should close and reopen tabs(windows)
I reported it few years ago through Microsoft Connect feedback, but bugs were closed due to it is "by design"
Update:
This is strange and irritating to see in desktop product developed during 2 decades, while this (autorefreshing) is being done by most webapplications in any browser
Related
So have a weird situation - a user on one machine can edit table columns (add or delete) without issue, but move to a newer machine and attempts to edit a table's columns results in an error message: "saving changes is not permitted"
Both SSMS are 18.12.1 and both have "Prevent saving changes that required table re-creation" enabled. This only happens on the new machines, all DBs work fine on the old machines and edits can be made with no issues.
To be clear, both installs of SSMS are completely default with no changes made and the same users test. Even SA accounts cannot make table edits on the new machines but can on the old machines fine.
Is there some SSMS setting that needs flipped or allow changes from another location?
This is NOT a duplicate of Sql Server 'Saving changes is not permitted' error ► Prevent saving changes that require table re-creation
Big thanks to #Dai and #Larnu for helping to figure out what was happening.
TLDR; Use TSQL for table structure changes. Don't use SSMS table designer.
This ultimately was something odd with the designer in SSMS and the code it generates not being consistent. In our instance, we were able to find an instance where the same designer change on two separate machines were outputting different ALTER code despite the change (adding a column) being the same. The oddities continue as after the correct ALTER statement is run, the designer in SSMS start working correctly, and consistently.
I suspect there may be more user variable actions involved in this as suggested by #Larnu but, with the use of TSQL as standard instead of the designer, we can just avoid the issue altogether.
I'm using a MS SQL Server db and use plenty of views (for use with an O/R mapper). A little annoyance is that I'd like to
use schema binding
update with scripts (to deploy on servers and put in a source control system)
but run into the issue that whenever I want to e.g. add a column to a table, I have to first drop all views that reference that table, update the table, and then recreate the views, even if the views wouldn't need to be updated otherwise. This makes my update scripts a lot longer and also, looking the diffs in the source control system, it is harder to see what the actual relevant change was.
Is there a better way to handle this?
I need to still be able to use simple and source-controllable sql updates. A code generator like is included in SQL Server Management Studio would be helpful, but I had issues with SQL Server Management Studio in that it tends to create code that does not specify the names for some indices or (default) constraints. But I want to have identical dbs when I run my scripts on different systems, including the names of all contraints etc, so that I don't have to jump through loops when updating those constraints later.
So perhaps a smarter SQL code generator would a solution?
My workflow now is:
type the alter table statement in query editor
check if I get an error statement like "cannot ALTER 'XXX' because it is being referenced by object 'YYY'."
use SQL Server Managment Studio to script me create code for the referenced object
insert a drop statement before the alter statement and create statement after
check if the drop statement creates error and repeat
this annoys me, but perhaps I simply have to live with it if I want to continue using schemabinding and script updates...
You can at least eliminate the "check if I get an error" step by querying a few dynamic managment functions and system views to find your dependencies. This article gives a decent explanation of how to do that. Beyond that, I think you're right, you can't have your cake and eat it too with schema-binding.
Also keep in mind that dropping/creating views will cause you to lose any permissions that were granted on those objects, so those permissions should be included in your scripts as well.
In visual studio datasource designer is there any way to refresh a table and its relations/foreign key constraints while keeping the custom queries?
The way I am doing it at the moment is removing the table and adding it again. This adds all the relations and refreshes all fields.
Also if I change a fields data type, is there a way to automatically refresh all the fields in the datasource? Again without deleting the table and adding it again.
Reason for this is because some of my TableAdapters have quite a number of complex queries attached to them and when I remove the table the adapter gets removed as well including all its queries.
I am using Visual Studio 2008 and connecting to a MySQL database.
Any1 have an idea?
Each table has a default query (The one on top with the check on it). When you dragged your tables in to the dataset to create the query, it wrote a SQL statement which it uses to schema your table. Keep that query simple, you might not actually use it in code, and you can always edit that query to update the table schema.
Every time you open the default query it connects to your datasource and allows you to select new columns that weren't in there before. If you want to update your existing columns, delete all the columns out of the table before you attempt to open the query. When you save the query, your updated columns get added back.
Make sure your connection string has permissions to view column information.
I reported this to MSFT but no response. The designer hangs all the time on the simplest of SQL statements. What I found that works for me is.
Add a new table to the designer.
Save it.
Shut down visual studio 2010.
Start VS 2010.
Add one or two more SQL statements and follow steps 2-4 again.
This is a pain in the neck but the only thing that stops Visual Studio dataset designer from hanging. I experienced in this same issue in VS 2008. I am connecting to Oracle but still shutting down VS and starting it back up works, but really, this is nonsense.
You can add/change/remove fields and relation ships, but i would suggest looking into NHibernate.
You should be able to right-click the dataset in solution explorer and select "Run Custom Tool" to refresh the table and it's query/relationships.
If that command is not there, check that the dataset properties has "MSDataSetGenerator" in the Custom Tool field.
Right click on your DataSet name and select Dataset Properties
Below the Query box you will see a button for Refresh Fields.
Click on Query Designer and the new field should show in your table list.
Using SQL Server 2008 and I'm doing some schema construction in the Management Studio designer.
I created a table early in the process called "Animal", but then decided to delete shortly after. I deleted it via the tree view in Management Studio (right-click delete).
Now I'm late in the process, I would like to recreate the table "Animal" but with different fields.
The second time round with Animal gets created fine, but when I try to add the table to my diagram I get the message "Table 'Animal' is marked for deletion, can't be added to the diagram or opened in the table designer".
What's the deal? How can I use this table normally again and not suffer from older table naming conflicts?
Alternatively, if the table is marked for deletion, can I actually invoke deletion somehow? Then recreate another table with the same name.
This is a little annoying. Would appreciate any help.
I was able to fix this problem by closing SQL Management Studio and re-opening it. I bet simply severing the connection to the server and reinstating it would work.
Just Severing the connection from SQL Management Studio did not work. But restarting the SQL Management Studio worked. Still better than restarting the system.
What worked: rebooting.
Restarting the entire computer worked.
Simply restarting the db server didn't work, but rebooting the entire machine did.
I have no idea why!
I know this is old, but I came across this same problem. I found the solution here:
http://weblogs.asp.net/atlaszhu/archive/2010/04/04/sql-server-2008-database-diagram-quot-saving-changes-is-not-permitted-quot.aspx
which basically says there is an option in the "Tables and Database Designers" section called "Prevent saving changes the require table re-creation" - when this is checked, you will receive errors like you've asked about.
When I disabled this option, I was able to save my database diagram.
If you're using the schema tool, it may be simpler to recreate the schema. In my experience I've found that tool to have some odd quirks that have been fixed by simply recreating the schema ( the graphical view of it, not the whole db :) )
From MSDN, to delete a table from the Visual Database Designer:
In your database diagram, select the table you want to remove.
Right-click the table and choose Remove Table from Diagram from the
shortcut menu.
-or-
Press the ESC key.
If the table has unsaved changes as a
result of edits you made in the
database diagram, a message prompts
you to save the table before removing
it.
The table is removed from your diagram
but it continues to exist in the
database.
So, to delete it, you'll have to do that from script or object explorer (MSDN):
To delete a table from the database
In Object Explorer, select the table you want to delete.
Right-click the table and choose Delete from the shortcut menu.
A message box prompts you to confirm the deletion. Click Yes.
There might be any link remaining of that table on any diagram just open DB diagrams and it will tell you that this table is removed.
Just close SQL Server Management Studio, disable network connection (unplug cable or disable wifi), re-open SQL Management Studio and reconnect the network. It should work fine now.
So, I'm using SQL Server Management Studio Express,it has been working not bad so far, ignoring some of the weirdness.
But I just happened to get a whole shwack of data deleted when I happened to delete a row in a parent table. So I thought I must have cascade deletes enabled in this relationship. But, how does one determine this?? If you double click a relationship in the DB Diagram, your only option is Delete, and the tooltip only shows you the FK relationship name.
This fellow had the same problem as me:
http://social.msdn.microsoft.com/forums/en-US/sqldatabaseengine/thread/1f9c1e8f-b719-476d-828e-91ac6722096a/
So, am I missing something, or is this another situation where a software company deliberately does a half assed job? I have an MSDN ultra (or whatever the highest level is) license, so will that be better, or, is there a 3rd party tool one can use??
In SQL Server Management Studio Express, don't you have the option to 'design' the table. (Right click on the table, then design) ?
Then, you should have an additional toolbar with an icon which looks like 3 tables and their relationships. The tooltip of that button says 'Relationships'.
When you click that button, you'll see the foreign key constraints of that table, and in the dialog box, you can specify the UPDATE & DELETE rules of the FK.
The diagram tool isn't great.
If you use the Object Explorer to open the Tables, open the table you're interested in, open Keys, you should be able to find your foreign key, right click on it and choose Modify (or choose to script it out (to window/file/etc)).
This works in SSMS 2008, haven't tried in 2005 Express, but I'd be surprised if it wasn't there (since it's basically functionality that was built into Query Analyser long ago)