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.
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 am using Visual Studio enterprise 2017 (Version:15.71.1) and SSDT(Version:15.1.61804.210)
and also using TFS to keep my code. In my database project all tables are temporal table.
Now when i am changing column type or column name in TFS , i am not able to build my project so not able to generate publish script.
I am getting error :
Error SQL71609: System-versioned current and history tables do not have matching schemas. Mismatched column:"XXXXX"
Do we have any solution for this ?
Generally you can try explicitly defining the history table, then manually keep the schema of the current and history table in sync.
Reference this thread: Avoid schema mismatch in System-Versioned tables
UPDATE:
As you mentioned the solution which worked for you is to make these changes in SQL Server Object Explorer (You can see it by right clicking on DB project and choosing the “View in Object Explorer” option). You need to do the modification here and just save it and it will work.
The solution which worked for me , is to make these changes in SQL Server Object Explorer (You can see it by right clicking on DB project and choosing the “View in Object Explorer” option). You need to do the modification here and just save it and it will work.
I am using Visual Studio Code with the mssql extension.
I am expecting intellisense to help me with table names and column names.
But if I type
SELECT * FROM dbo.
and press Ctrl-Space then I am hoping to see a list of tables. But I don't see anything. I believe my expectation that this should work is correct. Does anybody know how to fix this?
I am thinking now that this was because I hadn't established a database connection. So I was getting Intellisense on keywords but not database tables or columns.
Another thing that's worth noting for anyone else that comes across this issue is that if you don't specify a database name when connecting(because you have multiple DBs under a single connection) - you will connect to 'master' and won't get any IntelliSense on the schema. I suspect this is because different Databases could have different Schemas.
If this is your situation and all your Schemas are the same I would suggest creating two connections; one with a DB name specified and one without. You could then get the IntelliSense on your named DB editor window and Copy and paste your code into your editor window with the 'master' connection obviously adding the "use..." at the top of the window.
Hopefully a nicer solution to this issue is created but in the meantime this is what gets me by.
We just trying to implement SSDT in our project.
We have lots of clients for one of our products which is built on a single DB (DBDB) with tables and stored procedures only.
We created one SSDT project for database DBDB (using VS 2012 > SQL Server object Browser > right click on project > New Project).
Once we build that project it creates one .sql file.
Problem: if we run that file on client's DBDB - it creates all the tables again & it deletes all records in it [this fulfills the requirements but deletes the existing records :-( ]
What we need: only the update which is not present on the client's DBDB should get update with new changes.
Note : we have no direct access to client's DBDB database for comparing with our latest DBDB. We only can send them some magic script file which will update their DBDB to the latest state.
The only way to update the Client's DB is to compare the DB schemas and then apply the delta. Any way you do it, you will need some way to get a hold on the schema thats running at the client:
IF you ship a versioned product, it is easiest to deploy version N-1 of that to your development server and compare that to the version N you are going to ship. This way, SSDT can generate the migration script you need to ship to the client to pull that DB up to the current schema.
IF you don't have a versioned product, or your client might have altered the schema or you will need to find a way to extract the schema data on site (maybe using SSDT there) and then let SSDT create the delta.
Option: You can skip using the compare feature of SSDT altogether. But then you need to write your migration script yourself. For each modification to the schema, you need to write the DDL statements yourself and wrap them in if clauses that check for the old state so the changes will only be made once and if the old state exists. This way, it doesnt really matter from wich state to wich state you are going as the script will determine for each step if and what to do.
The last is the most flexible, but requires deep testing in its own and of course should have started way before the situation you are in now, where you don't know what the changes have been anymore. But it can help for next time.
This only applies to schema changes on the tables, because you can always fall back to just drop and recreate ALL stored procedures since there is nothing lost in dropping them.
It sounds like you may not be pushing the changes correctly. You have a couple of options if you've built a SQL Project.
Give them the dacpac and have them use SQLPackage to update their own database.
Generate an update script against your customer's "current" version and give that to them.
In any case, it sounds like your publish option might be set to drop and recreate the database each time. I've written quite a few articles on SSDT SQL Projects and getting started that might be helpful here: http://schottsql.blogspot.com/2013/10/all-ssdt-articles.html
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.