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.
Related
I try to add a nullable bit column (without a default value) in a table with 39 records in it. On saving the studio freezes and isn't able to execute the desired change. The connected application cant't be executed either, I get a timeout there. I tried to add the column via user interface and also via a SQL command, with no success in both ways.
The table I'd like to change has several related tables. In operation there is no writing access on the table, but many reading accesses. After rebooting the server I was able to add the column. The update process lasted unusually long anyway. Updating the same table on the same server in another, identical database which is used only from a few users worked fine (within a few seconds). Adding the column in the local database also worked without problems.
Unfortunately I couldn't find a way to solve my problem and I can't reboot the server every time I'd like to modify my table.
Hope you can help me.
I am new to Oracle SQL Developer (about 1 month of use), having always used Toad. I have 2 almost identical schema set up - one to test older code, one to develop a modified versions. I have 2 different connections set up - one to each schema, with separate user names for each one.
But when I delete a table or column from the schema in one connection, it is also deleted or changed in the other.
This happens if I right-click on the table or field in the Connection explorer panel, or if I open a SQL Script saved to disk. If I open a SQL script, I even see a pop-up that asks me what connection to use, but if I select one, it still makes changes to both. Even if I only have one of the two connections open, the script will still change design in both of the connections.
The only way I can be sure to make changes to just one of the two is to right-click on the connection name in the Explorer panel, and open a new SQL Worksheet. The worksheet is then named for the connection and just makes changes to it.
This is not the behavior I was expecting, and I'm facing many hours of work to get the definitions of the 2 schema back to where I need them to be. I am wondering if there is some key concept or distinction I am missing or if there is some way the database(s) are set up that is enabling this to happen.
In case you never found the answer for your question. This is my understanding:
The database may have several schemas. The schema is not a separate database, it is a grouping of objects in that database. If you change something while in one schema, you are really changing it in the database, not just the schema. I hope this helps.
Are you just trying to test things in one schema? It sounds like you may want to have a Database and a TEST Database. You could test whatever you wanted in the TEST database and never have it change the real database.
Up until today, I was able to use the Schema Compare feature in Visual Studio 2012 to update a database from a database project. But now, for one project I can do the compare, but the update button is greyed out.
I am able to use other projects to update other database, but from this project I can't update any databases. I do not get any errors, the functionality is just unavailable.
Using publish still works. Also updating the project from the database works, just not the other way around.
Does anyone know why I wouldn't be able to update a database via Schema Compare?
Check the bottom of the screen after a compare it shows status messages there.
I've seen this issue if there is a compile error in the database project. Once the error is resolved close and reopen the compare dialog. Rerun your compare and the Update button should be available again.
You must check database users and database schema. Often, if database users aren't correctly replicated in DB Project, Schema Compare doesn't work.
For me the error list pane and output pane weren't showing anything in Visual Studio 2015. Only after building the database project that I was targetting, was I able to see the errors in the output pane (but still not in the error list pane). After fixing these errors, the Update button was no longer greyed out.
Ran into the same problem myself. As mentioned above, the normal Visual Studio Error List will list errors that block update... but further, there will also be warnings. One of the options that's enabled by default is that data loss blocks the update. That's the problem. Even though it's only a warning condition, any possible data-loss is functionally an error unless you change this flag.
imho, this is a pretty severe UI failure on MS's part, but what are you gonna do?
What worked for me was including the schema.
I was selecting to include only certain tables / procs etc.
If the schema containing the tables and procedures is not also ticked, the import does not include the elements.
You need to ensure that all of your SQLCMD variables have default values.
Right-click onto the project within the Solution Explorer and select Properties.
On the tab to the left, go to SQLCMD Variables and enter the default value(s) into the column provided.
After running your schema compare another time, the update button should now be available.
In my case, the issue was that I had installed a newer version of SQL Server and SSMS (2016). You must always make sure you have the correct version of Sql Server Data Tools installed to match the version you are doing the compare against. Here is the link to SSDT for SQL Server 2005-2017 that I verified working with Visual Studio 2017:
https://learn.microsoft.com/en-us/sql/ssdt/download-sql-server-data-tools-ssdt?view=sql-server-2017
For me, I changed the order of the tables being added. If there is any relationship between any two tables, you have to add the parent table then dependent one to the database.
Not only does the schema have to be in your database project, it must be kept up to date if it changes on the database. Updates quit working after DBA granted a exec permission to a new sql login in the database on an schema that was in my project. After multiple failures for any stored procedure changes to get applied to my project, I updated the project, selecting only the schema that had changed. After updating the schema in the database project, the Update started working again. I include the schema in all updates. Hope this helps.
Within Schema Compare go to Options -> General -> check *Ignore authorizer*
This issue usualy is thrown if there was a change of tables in one of the two Databases since you've clicked "compare". Regardless weather the change happens on a table that is beeing updated or not.
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
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.