I need to backup a database, however it includes in development views (eg. dev.V_report). These views result in the following errors being reported when I attempt to create a DACPAC file via SSMS > Extract Data-tier Application:
Validation of the schema model for data package failed.
Error SQL71501: Error validating element [dev].[V_MasterFinanceReconciliationSummary]: View: [dev].[V_MasterFinanceReconciliationSummary] has an unresolved reference to object [dbo].[V_MasterFinanceFull].
Error SQL71501: Error validating element [dev].[V_MasterFinanceReconciliationSummary]: View: [dev].[V_MasterFinanceReconciliationSummary] has an unresolved reference to object [dbo].[V_MasterFinanceFull].[PasTransactionType].
… (etc)
Every view with an issue is limited to the dev schema, they can't be guaranteed to not have these issues, and I'm unable to move these to a different database. I just need to backup the table schemas, and while I can deselect tables in Extract Data-tier Application I can't do the same for the problematic views, or the dev schema as a whole.
I've tried creating a BACPAC as that would still function as a backup, but I encounter the same issue. I've tried backing up the database using SqlPackage.exe in the command line using the following (using Azure AD Login, which is required here):
sqlpackage.exe /TargetFile:"C:\temp\DACPAC\output_target.dacpac" /Action:Extract /SourceServerName:<server> /SourceDatabaseName:<database> /ua /p:VerifyExtraction=False
But this just gives me the following error which I can't find relevant information on:
*** An unexpected failure occurred: Exception has been thrown by the target of an invocation..
Any advice on backing this up would be greatly appreciated.
Please consider to create a copy of the database. Remove all views on the newly created database using a script. Then export the database the newly created database with all views removed as a bacpac.
Related
I am planning on using SSMS, why I am unable to run Tasks->Export Data Tier Application on a database which has views pointing to another database tables. This is in Azure SQL MI.
Error Message
One or more unsupported elements were found in the schema used as part of a data package.
Error SQL71561: Error validating element [dbo].[vw_ext_customer]:
View: [dbo].[vw_ext_customer] has an unresolved reference to object
[finance].[dbo].[ext_customer]. External references are not supported when
creating a package from this platform.
External Table View
CREATE VIEW [dbo].[vw_ext_customer] AS SELECT * FROM finance.dbo.ext_customer
Finally, I am able to generate bacpac using sqlpackage utility instead of SSMS. Trick is not to verify schema model during export. Not sure why SSMS do not have this parameter or am I missing somewhere. Please find my working code below
$ sqlpackage /a:export /ssn:some_server /sdn:databasename /su:username /sp:password /tf:database.bacpac /p:VerifyExtraction=False
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 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.
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.
When I'm publishing a new database that contains multiple filegroups and files, the file groups dont get published on the creation of a DB. When the DB is being upgraded it works, which means I need to call sqlpackager.exe twice to publish a database.
Objective:
Create a database with filegroups(shared component) that break up configuration data from sales data.
Implementation:
Main database project references a common database project that contains a collection of file groups only. The DB reference has been correctly set up. The publish file being used with the deployment of the dacpac correctly sets the property: IgnoreFileGroupPlacement (FALSE)
The main database project has a list of files to add to the file groups.
I'm creating a filegroup called "defaultworkingspace" to move everything off primary except system objects, i've marked this filegroup as default.
When I deploy for the first time, I get the below error:
Initializing deployment (Start)
*** A project which specifies SQL Server 2008 as the target platform may experience compatibility issues with SQL Server 2005.
*** The following SqlCmd variables are not defined in the target scripts: SourceCode SourceId.
Initializing deployment (Complete)
Analyzing deployment plan (Start)
Analyzing deployment plan (Complete)
Updating database (Start)
Creating Register_DB...
An error occurred while the batch was being executed.
Updating database (Failed)
*** Could not deploy package.
Warning SQL0: A project which specifies SQL Server 2008 as the target platform may experience compatibility issues with SQL Server 2005.
Warning SQL72013: The following SqlCmd variables are not defined in the target scripts: SourceCode SourceId.
Error SQL72014: .Net SqlClient Data Provider: Msg 5014, Level 16, State 2, Line 1 The filegroup 'DefaultWorkingSpace' does not exist in database 'Register_DB'.
Error SQL72045: Script execution error. The executed script:
ALTER DATABASE [$(DatabaseName)]
MODIFY FILEGROUP [DefaultWorkingSpace] DEFAULT;
The setting of the default has been made as part of a post deployment script so it should be running with all post deploy scripts. When I deploy it again, now as an upgrade as the db has been created
Initializing deployment (Start)
*** A project which specifies SQL Server 2008 as the target platform may experience compatibility issues with SQL Server 2005.
*** The following SqlCmd variables are not defined in the target scripts: SourceCode SourceId.
*** The source's object [Register_DB] is different than the target's version of the object but the target object will not be updated.
*** The object [Register_DB] already exists in database with a different definition and will not be altered.
Initializing deployment (Complete)
Analyzing deployment plan (Start)
Analyzing deployment plan (Complete)
Updating database (Start)
Creating [Configuration]...
Creating [DefaultWorkingSpace]...
Creating [Giftcards]...
Creating [Logging]...
Creating [MasterData]...
Creating [Mobile]...
Creating [Sales]...
Creating [Config]...
Creating [Working]...
Creating [Giftcards]...
Creating [Logging]...
Creating [Master]...
Creating [Sales]...
It seems odd that the upgrade process supports the filegroups but the initial creation of the DB does not... Has anyone come accross this issue before?
Known issue with dacpac apparently.
I went with the approach of deploying a db project to master prior and creating the db's if they didn't exist in post scripts for that db. Not the cleanest but it'll do for now.