We have a database project with views which join to tables in another database. The other database is in a different solution. This failed to build until we added a reference to a DacPac from the other database. I believe these views are considered “Composite Database Objects” because they reference objects not included as scripts in the database but rather referenced in the DacPac. We can successfully deploy this project from the VS to the target database.
Now we are trying to automate the deployment via MSDeploy. We have successfully deployed non-Composite database projects using DacPacs in the past by creating a package from a manifest. For example:
But in this case the deployment fails with the following error:
Error SQL0: The reference to external elements from the source named
'Other.dacpac' could not be resolved, because no such source is
loaded. Warning SQL72025: No file was supplied for reference
Other.dacpac; deployment might fail. When package was created, the
original referenced file was located D:\BUILDS\6\CORE SERVICES\ACME DB
(DEV2-DEPLOY)\SOURCES\ACME.SQLDEPLOY\DACPACS\Other.DACPAC.
Error: An error occurred while adding references. Deployment cannot
continue. Error count: 1.
Is there a trick to make sure the referenced DacPac makes it into the package and the deployment completes successfully?
In the end we had to:
Unzip the DacPac
Change the path of the referenced DacPac to be relative
Recalculate the checksum and update it
Rezip the DacPac
Not ideal, but in the end we now have an automated deployment process for DacPac referencing DacPacs.
This is an old question, but we've found that if the DACPAC cannot be found on the path referenced, you can include it in the same directory as the referencing DACPAC.
e.g., if ABC.dacpac references the msdb database, the referencing location is expected to be at C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\SQLDB\Extensions\SqlServer\120\SqlSchemas\msdb.dacpac
However, you can copy msdb.dacpac to the same directory as ABC.dacpac and Microsoft.SqlServer.Dac.DacServices will find it
Related
I have a Visual Studio SSDT project where one view references a linked server via 4 part naming. I have set up a project for the database on the linked server and created a reference from the main project to the "linked server" project, and all works fine.
I have been instructed to use OpenQuery instead of 4 part naming convention because actually OpenQuery does run 2-3x faster than query via 4 part naming convention.
However, when I change the view in SSDT to use open query, I get an error:
Severity Code Description Project File Line Suppression State
Error SQL71501: View: [schema].[view] has an unresolved reference to object [LINKEDSERVER].
I have tried defining [LINKEDSERVER] in a script in the project:
exec master.dbo.sp_addlinkedserver #server = N'LINKEDSERVER', #srvproduct=N'SQLSERVER', #provider=N'SQLNCLI', #datasrc=N'SERVERNAME'
And also tried adding same into the referenced project.
So, how to incorporate OpenQuery into an SSDT project without incurring SQL71501/'unresolved reference to object' errors?
I’ve been fighting this same issue for a while. I solved by:
Importing the master.dacpac that included the needed Linked servers.
Creating a database reference from the calling database to the DACPAC of the database I'm referencing (insure Suppress Reference Warning is checked).
used the syntax OpenQuery([LINKEDSERVER], ‘xxx’); and not OpenQuery([$([LINKEDSERVER])], ‘xxx’);
I hope this helps!
Is there a way where the database references in a SQL Server Database project (Dacpac) can be derived at run time?
We're building a product which uses Dacpac to deploy database objects.
Our product implementation teams also use Dacpac projects by adding database reference to the product Dacpac file and then adding their own additional objects to the project.
The problem we're facing is - every time the implementation needs to point to a newer product release version, the parent dacpac references in the implementation dacpac have to be changed manually to refer to the new file path of the new product dacpac (in the newer release). We've mutiple implementation teams and multiple database projects in each implementation.
Is there any way the database references (*.dacpac) in a database project can be derived at run time using a variable or parameter or something of that sort?
My understanding of your question is as follows:
You have a SSDT database project (see example image below), that has a database reference (similar to #1 below) with stored procedures and other db objects that access the reference database (similar to file #2 and code #3). You've 'built' the solution resulting in a DACPac and now you want to take this DACPac and reference other databases at deploy-time. Hopefully I understood your question correctly.
If so, then you can use the Publish Profiles feature to achieve this (similar to #4 below).
The code for this can be seen in my notes from my SSDT talk github project.
If you look specifically at the demo04 solution file, you will see that I have a DEV_MJE.deploy.ps1 PowerShell file and a DEV_MJE2.deploy.ps1 file. These scripts run MSBuild to build the DACPac and then use SqlPackage to publish DEV_MJE.publish.xml or DEV_MJE2.publish.xml respectively. Note, if you run this example on your machine, you'll need to add MSBuild.exe and SqlPackage.exe to your path, as well as modifying the TargetConnectionString in the xml files to an existing development database.
As an example of how this works...When I use the Publish Profile DEV_MJE.publish.xml, the resulting GetDataFromAnotherTable.sql file contains:
SELECT [SomeData] FROM [AnotherDb_MJE].[dbo].[AnotherTable]
Whereas when I use DEV_MJE2.publish.xml the resulting GetDataFromAnotherTable.sql file contains:
SELECT [SomeData] FROM [AnotherDb_MJE2].[dbo].[AnotherTable]
Notice the database reference in the second has changed to AnotherDb_MJE2.
For a good description of how Publish Profiles relate to DACPacs and SSDT Database Projects, see this web page. It also contains information on alternative ways to deploy beyond SqlPackage.exe.
Something else to consider
Note, that using file paths to version control a DACPac is not really the best practice. Consider the DACPac artifact as similar to a .Net DLL. It is the biproduct of a build.
As such, a better approach is to use NuGet and tools like Octopus Deploy to store, track, and deploy DACPacs. See the stackoverflow answer for a good description of how this works.
Hope that this helps,
Michael
Thanks for the followup comment, I think what you are trying to do is when you write and deploy your code be able to use different dacpacs depending on the project?
Each implementation team might have a different version of the shared dacpac deployed so you can't just put the files in a shared location and call the dacpac "Product_Latest.dacpac" or something, so everyone always gets the latest version.
".sqlproj" files are standard msbuild scripts and references can be managed using msbuild properties so you can technically change the reference at runtime. If you edit your .sqlproj file and add a property in the first <PropertyGroup> tag, I used:
<ProdDacpacVersion Condition="'$(ProdDacpacVersion)' == ''">v1</ProdDacpacVersion>
v1 is the unique name for the version folder - you just need something to identify the dacpac you want.
I put the property just after TargetDatabaseSet and IncludeCompositeObjects.
If you then find the reference to the dacpac and instead of
<ArtifactReference Include="..\..\..\..\..\Desktop\prod\v1\Database2.dacpac">
<HintPath>..\..\..\..\..\Desktop\prod\v1\Database2.dacpac</HintPath>
<SuppressMissingDependenciesErrors>False</SuppressMissingDependenciesErrors>
</ArtifactReference>
Use the property from above:
<ArtifactReference Include="..\..\..\..\..\Desktop\prod\$(ProdDacpacVersion)\Database2.dacpac">
<HintPath>..\..\..\..\..\Desktop\prod\$(ProdDacpacVersion)\Database2.dacpac</HintPath>
<SuppressMissingDependenciesErrors>False</SuppressMissingDependenciesErrors>
</ArtifactReference>
Then the reference will use the property to get the path of the dacpac. There are a few ways you can set the property, you could edit the .sqlproj file when you want to take a new version of read the property from a file or environment variable or something (i'll leave the msbuild fun to you!).
I would, as a standard, everytime the reference was changed either reload the project or restart visual studio - it won't take long and it will save lots of cursing :)
When you deploy the dacpac's, the deploy looks in the same folder for references first so just make sure you copy the right one into the bin folder when you deploy.
I have installed Flyway in my server and trying to execute a My-sql file which I placed in sql folder of flyway.
I have done Flyway baseline, and when I run flyway migrate it says "Schema xyz is up to date. No migration necessary." No matter what I do it always gives me the same result.
My sql files are named 1__act.sql, 2__act.sql, 3__act.sql.
My config file has
flyway.url=jdbc:mysql://mysql:port/xyz
flyway.user=flywayuser
flyway.password=flywaypassword
flyway.baselineVersion=1
You haven't followed the naming conventions for Versioned SQL migrations, they should be prefixed with a V. e.g. V1__act.sql.
Note that the prefix is configurable, but above is the default.
/src/main/resources/db/migration needs to be a source folder in Eclipse/Spring Tool Suite. Right-click it, Build Path, Use as Source Folder.
I am using DNN 7.3 for a website project which is a combination of VB and C# codes. I use visual studio 2013 to build the project.
If the MSBuid Option in property page is configured to Allow this Precompiled site to be updatable and the project is published.
There will be a successful built. But when it is checked in to the TFS, the following exception will be thrown:
/compiled/DesktopModules/Admin/Security/manageusers.ascx (8): Circular file references are not allowed.
/compiled/DesktopModules/Admin/Security/manageusers.ascx (67): Unknown server tag 'dnn:profile'.
/compiled/DesktopModules/Admin/Security/EditUser.ascx (5): Circular file references are not allowed.
/compiled/DesktopModules/Admin/Security/EditUser.ascx (163): Unknown server tag 'dnn:Profile'.
/compiled/admin/Users/ViewProfile.ascx (4): Unknown server tag 'dnn:Profile'.
Also, when I checked Use Fixed Naming and Single Page Assemblies together with the Allow this Precompiled site to be updatable. it will throw:
ASPNETCOMPILER: Object reference not set to an instance of an object.
when I searched online, I was given two options from this blog.
I have tried the two but still having the same error.
I don't know what I am doing wrong.
Please look at [here] (http://ellisweb.net/2009/12/fixing-the-circular-file-references-are-not-allowed-error-in-asp-net/) for the explanation why you would see this error, simply speaking, if you have the following setup:
/folder1/Control1.ascx > References Control2
/folder2/Control2.ascx > References Control3
/folder1/Control3.ascx
This means that the folder1 dll will reference the folder2 dll which will again reference the folder1 dll, causing a “circular file reference”.
The solution is try to rearrange all controls under each folders, sometimes, you have to make a problem user control copied over to multiple folders to prevent such circular calling.
I changed The Clean WorkSpace property of TFS Build Process Parameters to false.
The error just disappeared and I was able to build successfully into TFS Drop folder. I don't know why this solves the problem but the problem was resolved.
We are updating a BizTalk 2009 application that I inherited. I'm converting them into BizTalk 2013 R2.
I get the following reasonably famous error, when I try to re-compile
Exception Caught: Cannot load source/destination schema: MyCompany.Schema.AppConfig.
Either the file/type does not exist, or if a project dependency exists, the dependent project is not built.
There are only two posts in SOF related to this error:
Biztalk Map Destination Schema Imports Multiple Schemas
Reference trouble with BizTalk schema project in Visual Studio 2008
and only a few meaningful posts in elsewhere.
The solution has 4 projects organized as follows:
Common (contains an 1 schema AppConfig.xsd file)
Orchestration (1 Orchestration file)
Schema (references an ASMX web service)
Map (1 map file, references Schema and Common Projects)
The Map project attempts to translate an source message of type AppConfig to the type AppConfigBE which is one of the Complex Types in the Web Service.
I keep getting the compile time error above.
Tried all of the following, as recommended in the two SOF posts, and a few other posts on MSDN forums, but none of it worked.
Tried alternating Copy Local on the Maps project (From true to false, and vice-versa)
Tried Replacing schema on source and destination on the map file
Schemas are referenced using fully qualified .Net type name
Tried referencing the .dll as opposed to the Schema and Common projects.
Updated the web reference; also removed and re-added the web references
Is there a solution/hot fix etc for this? Any other suggestions I can try?
UPDATE 1:
We had to call Microsoft for help; the engineer took my project file to try on their computers; he said they too had the same problem and as a fix, recommended to set the Build Action property of the .BTM map file to None instead of BTSCompile. After this, the project builds successfully. He said to test the project with this build and let them know. What I'm not sure is, what are consequences of this? Many topics on Build Action refers to the schema files, not the map files in a BTS project. What is the standard Build Action for Map files?
One more item is to clear any Assemblies from the GAC or re-GAC them with a Post-Build script.
I ran into the same problem. I needed to add
using Microsoft.XLANGs.BaseTypes;
using Microsoft.BizTalk.XLANGs.BTXEngine;
[assembly: Microsoft.XLANGs.BaseTypes.BizTalkAssemblyAttribute(typeof(BTXService))]
to the AssemblyInfo.cs into the project.