I have a problem with unresolved referenced in synonyms with a VS2013 Database project I have created for Team Foundation Server, which cause the project to not build. The synonyms reference another Database on the same server. I have seen online there are 3 main ways people handle this. I am going for this approach 1.
Create a DPAC file and add as a Database reference in Visual Studio Database Project.
Bring in the other database project in the current team Foundation Server project ?
Set the build action to None for the failing scripts that have the unreferenced synomns.
So when I go to extract the DPAC file from the Database it fails with an error.
Validation of the schema model for data package failed.
Error SQL71564: Error validating element [UAT_*********]: The element [UAT_*****] has been orphaned from its login and cannot be deployed.
( There is about 9 similar messages with other logons as well)
Is there anyway to bypass this and generate a valid DPAC file from sql server ?
If you need a .DACPAC file as a reference to your database projects, there is no need for referencing object to have any real code - As long as the signature met the requirements that the reference from Database Project was looking for, it will be just fine (syntactically valid).
You do not have to create a .DACPAC directly from SQL Sever, you can create a new empty Database Project, create/import all objects needed as references and then "Snapshot Project". This will generate valid .DACPAC and keep the size to minimum, which then you can put under source control.
If you wanted to create a .DACPAC from SQL Server, then I am afraid you would have to delete those objects, because it is unable to find logins in master database that are associated with them.
Great article to read about your approach 1 :
A complex database project
Hope this helps.
Related
I'm converting an existing DB into SSDT project and getting a ton of these errors, despite having added the reference to master DB. They can't be ignored because they're errors, not warnings, so it won't build.
Error SQL71501: View: someschema.someview has an unresolved reference
to object [sys].[dm_hadr_fabric_continuous_copy_status].
Error SQL71561: View: someschema.someview has an unresolved reference
to object [master].[sys].[server_resource_stats].[start_time].
It looks like master DB is outdated and doesn't recognise several views in Azure SQL Managed Instance. Is there any way to get afix this or get an updated master dacpac so I can build this project?
To resolve the SQL71561 build error please follow:
Add a reference to the other database, clear out the "Database variable" field in the dialog. If you don't clear this field, when doing a schema compare, SSDT would generate the script using the database variable name, which would fail.
Add a Database Reference to the project.
If in case the other database was another project in the same solution, you would be able to select it in the first drop down on the "Add Database Reference" dialog.
Make sure the text in the "Database name" field is correct.
Clear out the "Database variable" field.
Look at the "Example usage" text and verify that it looks as expected. Click "OK" to add the reference and that should take care of the 'unresolved reference' errors.
After doing this, you will be able to do a schema comparison, but could get the following error:
Error 408 SQL00208: Invalid object name 'db.schema.table'.
Go to the project properties and uncheck "Enable extended Transact-SQL verification for common objects" will allow the project to build successfully.
Consider and follow the below steps when converting existing DB to SSDT:
Create a new SSDT database project
Import the existing DB into that project, which will recreate all the script files and change the way they are organized/grouped
Do some cleanup on a few of the script files, including the post-deploy script
If it is SQLCLR project, make sure master DB stuff has done right (creating logins)
4.1 Make sure SQLCLR is enabled and configured correctly in the SSDT project's SQLCLR property page
4.2 Copy the source code for the SQL CLR into the top level of the project
4.3 Add the references need by the SQL CLR code
Compile
Publish
I'm using Visual Studio 15.8.5 with Sql Server Data Tools 15.1.
I've created an SQL Server database project and imported the schema of an already existing database. I've made several minor changes to a few tables of the database and published the updates to the development database without any problems.
After adding a few SQL scripts to the project, all of them with:
Build Action = None
publish fails, despite no changes have been made in any of the database objects of the project.
This is the part of the auto-generated publish script that causes the problem:
/*
The table [lut].[KAE] is being dropped and re-created since all
non-computed columns within the table have been redefined.
*/
IF EXISTS (select top 1 1 from [lut].[KAE])
RAISERROR (N'Rows were detected. The schema update is terminating
because data loss might occur.', 16, 127) WITH NOWAIT
GO
Table [lut].[KAE] has not been changed, though. One of the scripts is redefining its schema but this should make no difference since this is a 'No Build' script.
What am I possibly doing wrong here?
Edit:
I've done a schema comparison as #MadBert advised. I originally used my actual database as source and my sql server visual studio project as target. No differences were found.
I then switched source and target databases and compared again. The following 'difference' was detected.
As you can see this is not an actual difference, it looks like a Visual Studio bug in schema comparison. Any ideas on how I could circumvent this behavior?
It turned out that a refactor log file was the culprit.
I tried to publish to an empty database, as #Ogglas wisely advised. I noticed that during publish I was getting the following message:
The following operation was generated from a refactoring log file
8e659d92-10bb-4ce9-xxxx-xxxxxxxxx Rename [lut].[KAE].[xxxxx] to
$$$$$$$$$ Caution: Changing any part of an object name could
break scripts and stored procedures.
I then noticed that my SQL Server Database project contained a .refactorlog file
It seems that this log file was generated after I changed the offending table schema. The schema of the table was later reverted to its original state but the log file remained.
I deleted this log file and after that publish finally succeeded!
Had a similar problem when a SQL Server Database project was set to the wrong Target platform. Edit this in project properties to match the target server. Initiate a schema compare again by right clicking on the project and select Schema Compare....
Also check if Ignore whitespace is marked in Schema Compare Options. If you still have a difference one way or another try pasting the text in Notepad++ with Show All Characters on and see if you can spot a difference.
If you still can't find any difference, try creating a new database from the project and use SSMS GUI to compare. Does the table have the same Lock Escalation settings etc?
Having installed Sql Server Data Tools, I am attempting to use SqlPackage.exe from: C:\Program Files (x86)\Microsoft SQL Server\120\DAC\bin\
I'd like to "extract" schema and data. This is so I can migrate to a new Server that does not have any existing database - I want the schema and data to be included in that migration. This is just a spin up / throwaway environment.
The existing databases aren't great in that they have cross database references. The database I want to export has multiple references to another database named "audit". Triggers are involved - hopefully you get the picture.
Having read the docs, I tried this command:
.\sqlpackage.exe /Action:Export /SourceDatabaseName:"MyDb" /SourceServerName:foo\bar /TargetFile:"C:\temp\mydb.bacpac"
However this resulted in many of the following errors:
Error SQL71562: Error validating element [dbo].[foo_u]: Trigge
r: [dbo].[foo_u] has an unresolved reference to object [Audit].[dbo].[Foo].[FooId]. External references are not supported when creating a package from this platform.
I tried specifying /p:VerifyExtraction=false but this resulted in:
.\sqlpackage : *** 'VerifyExtraction' is not a valid argument for the 'Export' action.
So now I am thinking wow this must just not be supported. However in VS2017, when I went to SQL server explorer, I can "Extract data tier application" and choose options for "Extract schema and data" for all tables. This runs fine and produces a "foo.dacpac" file - the UI provides an option for "verify extraction" which I leave unchecked.
Now I am doubly confused because I thought dacpac files contain schema only, and bacpac files were for schema plus data - yet when extracting a data tier application "with data" via visual studio it produces a dacpac file. Does this mean I need to be using the "Extract" action rather than the "Export" action of SqlPackage.exe?
Can anyone offer any guidance on this?
This is what I have discovered.
To extract schema plus data, you need to use /Action:Extract NOT /Action:Export.
"Export" produces a bacpac file containing data. This will fall over in case of objects in the source database (triggers, sprocs etc) having external references. Seemingly no way to workaround this.
"Extract" produces a dacpac file, and has the option to also include data, and also you can disable the validation (disabled by default) so you can work around the fact that you have references to external objects.
It seems that Export has been neglected in terms of it's capability, and Extract is more flexible.
This was very confusing.
I am trying to implement this idea https://www.sqlshack.com/continuous-integration-sql-server-data-tools-team-foundation-server/ and I am getting this error:
Error Deploy72002: Unable to connect to master or target server 'DatabseTest'. You must have a user with the same password in master or target server 'DatabaseTest'.
I did the idea in a very simple way I created a database for the test in a Development server (just one table with an ID and Name columns), I created a database project on the visual studio, I create a script to insert a few rows in the only table in the database. Then I create a publish profile, I added the connection to the 'DatabaseTest' in the 'DEV' server, the user I am using for the access to the database is a user with admin permissions, the script associated with the publish profile is the only script in the solution the one for insert the rows. I made the check in and I created a build definition. I am trying to make the project build successfully, so I just add a Build Solution Task, in the MSBuild Arguments this is what I am passing:
/t:build /t:publish /p:SqlPublishProfilePath=Database_Testing_Profile.publish.xml
And I am getting the error from the beginning of the question.
Can someone please give an idea, about what is the problem??
Thank you.
First, The password won’t be stored in publish profile file after saving it, you need to add it manually (User Name=XXX;Password=XXX)
Secondly, sure the Target Platform is correct (Right click the project=>Properties=>Project Settings)
On the other hand, there is an article that may benefit you: Using MSBuild to publish a VS 2012 SSDT .sqlproj database project the same way as a VS 2010 .dbproj database project (using command line arguments to specify the database to publish to)
Ok, there are a bunch of posts about this, but all different versions of the problem. I could not find a post with my specific (albeit, basic) version of the problem. First, these are the steps that I followed to create a database project in Visual Studio 2012 (shell) with SQL Server Data Tools (SSDT):
Create new project, SQL-> database project
Right click on project, choose "Compare Schema"
Set source (SQL Server instance on a server)
Set target (local database project - the current project)
Run the "Schema Compare"
Update the target
This gives me a populated database project of all the objects in SQL server database. However, upon building the project, I get 200+ errors of unresolved references:
X- contains an unresolved reference to an object. Either the object does not exist or the reference is ambiguous because it could refer to any of the following objects: X, Y, Z
AND
X- has an unresolved reference to object
Adding a database reference to Master cut the errors down to 127, and now it's more manageable, but this not resolved. It only affects 5 or 10 objects out of 100's. Here's some things to keep in mind:
Only one database is used in the SQL Server objects (views, etc.)
Only 2 part naming ie (dbo.Table as T)
The "Enable Extended Transact-SQL verification for common objects" option is not present in my version of VS 2012, this feature was removed by Microsoft, and is already turned off.
I ran the command line sqlpackage.exe and created a dacpac of the database, this was then added as a database reference.
The database project will still not build. The errors only pertain to certain views and procedures. Has anyone had this problem?
Ok, I found the problem....
There are fields in a table that have their names padded with spaces, ie:
[Field1 ]
The views, procs, etc that reference those fields of course only use the name portion without padding, ie:
Field1
That name [Field1] is acutally wrong, the real name is [Field1 ] This caused the schema to break.
The tricky part is.... they still work in SQL Server. Although SQL Server shows these field names in a query with errors, it still is able to successfully process the query! I feel like there is some setting that has been turned off server-side... Anyway, SQL Server should have never allowed those statements to successfully run and the problem would have been caught.