I have set up my sqlproj project structure based on object type using the import Database wizard and using the Object Type as the folder structure. ie the same view as you'd get in SSMS or SQL Server Object Explorer
Yet when using ssdt schema compare to update the project, objects are always imported into Schema\Object Type structure, causing the project to turn into a mess of mixed structure.
I cant find anywhere I can change the behaviour of the Schema Compare update to continue to use the Object Type structure?
using ssdt 14.0.51215 (Dec 2015)
I would suggest submitting this feedback as a suggested improvement to Microsoft at https://connect.microsoft.com/SQLServer/feedback/CreateFeedback.aspx using the category "Developer Tools (SSDT, BIDS, etc.)"
you'll have to update the sqlproj file directly...
<PropertyGroup>
...
<DefaultFileStructure>BySchemaType</DefaultFileStructure>
...
</PropertyGroup>
More info on this link... https://social.msdn.microsoft.com/Forums/sqlserver/en-US/e6bfd561-3e7d-4052-be9c-631037681c3e/default-file-structure?forum=ssdt
Related
We have a SQL 2019 database where all table names are fully qualified in views starting with the database name. We do NOT have the option of avoiding the fully qualified reference as the view definition is auto-generated (otherwise I would simply not fully qualify them). When views are defined by referencing tables within the same database as the view, the SSDT project complains that it has an unresolved reference.
Visual Studio does not allow adding a database reference to itself. The only way I can get it to compile is to create a DACPAC of the same database and then add that as a reference along with removing the database variable ($Name).
Is there any other method of providing fully qualified table names in views without having to create a DACPAC in SSDT project?
Only way I'm aware of would be to take the view code out of the project and handle in post-deploy scripts. This is done by design, because the database name may not be what was defined in the original code.
You can't use 3-4 part naming in SSDT normally. You can workaround this by using variables in the code. So let's say, that you have [localhost].[reports].[dbo].[your_table] you'll need to use [$(ReportServer)].[$(ReportDatabase)].[dbo].[your_table].
I have a DacPac project containing objects which use three part naming to refer to the containing database (hundreds of instances such as [thisDb].[dbo].[obj]* exist). I need compare and update this database, but the db project fails to build due to 200+ sql71561 errors.
I did not want to remove the unnecessary database name part or switch to using a database name variable. To successfully build (or compare, and then update) a database using three part naming or fully qualified naming to refer to itself, there is a way I found to pacify visual studio. It's not what I'd prefer, but it works.
Create a copy of the original db project.
In the copy db project, update all local database object references to use just two part names ([dbo].[obj]) instead of three part names (I used find & replace).
Make sure the copy db project targets the same SQL server version and builds successfully.
Reference the copy db project from the original db project (whether via database variable, database name only, or dacpac).
The original db project can now build because its references can be resolved. You'll end up with a dacpac for both the original and the copy, but at least the errors are gone and it compiles.
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 imported a Form object from a text file. When I try to compile it I get the following error message:
This message is for C/AL programmers:
The OLE control or Automation Server identified by 'Microsoft Common Dialog Control 6.0 (SP3)'.CommonDialog requires a design time license.
This license cannot be obtained.
Make sure that the OLE control or Automation server is installed correctly with an appropriate license"
I am developing in Dynamics NAV using a developer license. The OCX is registered correctly, gets listed in NAV's "Custom Controls" as pointing to "C:\Windows\SysWOW64\comdlg32.ocx".
Why am I not allowed to compile the object?
The license in question is, as you said, purely for using the CommonDialog component in design-time environments. This has nothing to do with your NAV license or your customers being able to run code that uses the component. The design-time license (which is nothing more than a key in your system registry; not an actual license file) used to get installed with e.g. Microsoft Visual Basic 6.0 or older versions of Microsoft Visual Studio.
If you have access to VB6.0 or VS2005, you can use VB6Controls.reg on the installation disk as described here: http://support.microsoft.com/default.aspx?scid=kb;en-us;318597.
As the message said, the components loads, try to get a license and don't get one. So you don't have one as it says or you don't have it in the path lookup the components looks at it.
There is one more trick you can do to fix this problem and avoid installing a lot of crap like VB6.0.
This message is related to certain automation type variable in the object you trying to compile.
You can copy this variable from any other compiled object in other database or any other compiled object in the same database. And then your imported object will magically compile. Just delete the variable from your imported object's variable list and copy it from compiled object with copy-paste.
I don't know what magic is that but it worked for me many times. I copied variable from the same object in restored backup of the database.
I am using MyGeneration.dOOdads which helps in generating Business layer and Data layer easily, but currently I am facing a problem with it.
I had worked with MS SQL database and was successful, but now I have to work with MySQL 5.
I have the generated data layer classes of MySQL database successfully, but when I add them in my project along with the reference of MyGeneration.dOOdads dll file it gives error of no MySql4Entity class in the namespace.
I have generated the class according to the given instructions and also added the reference of mysql.data in the project but still this error is occuring.
Please guide me if you have used MyGeneration.doodads for MYSQL5 database in asp.net.
Also please tell me how to make stored procedure using MyGeneration.doodads of MYSQL database?
open doodads project (source code) .. right click on MySql4Entity class (and other classes related to mysql) and choose 'properties' the choose build action as 'compile' from the list ... to compile the file then build the project and it its output as reference to your project ...
How to update .dbml file after making some changes in the database.
There's no built-in way to sync the dbml file/datacontext with the database after making changes (besides regenerating the entire dbml file by removing all or a selection of the entities and re-dragging them, or by using sqlmetal as suggested by other replies), but there are third-party tools that add refresh functionality to the Visual Studio L2S designer.
One such tool is my add-in, Huagati DBML/EDMX Tools. You can download it from http://www.huagati.com/dbmltools/ and get a trial license if you want to take it for a test spin.
Jim Wooley has a summary various Linq and Linq-to-SQL tools here:
http://www.thinqlinq.com/default/LINQ-Tools.aspx
...and Damien Guard has a list of tools/resources for L2S here:
http://damieng.com/blog/2009/06/04/linq-to-sql-resources
The only way to do this is to delete the objects from the dbml interface, and re-add them back. Make sure that you hit Refresh in the Server Explorer panel after making changes to the database so that Visual Studio picks up the latest changes to the database when it creates the objects in the dbml.
SQLMetal is the tool you want. It installs with Visual Studio as part of the SDK. For most dbml, however, I've found the delete/re-add technique to be a bit more expedient and reliable.
There is no way to auto refresh the DBML to match the database. If you have added new tables to the datbase you can simply drage them into the designer window. If you have added or changed fields on existing tables or altered foreign keys/relationships, your best bet is to manually edit the classes and properties in the DBML file. ~You can delete them and the drag them back in from server explorer which will refrech them from the datbase but you will lose any custom modifications you have made such as changing properties from public to protected or setting up inhertance or other things.