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.
Related
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.
It seems like I always have a variety of problems doing this, and usually I end up nuking the db out of frustration and rebuilding, but obviously there has to be some way to do this.
I have an existing asp.net mvc web app living with its sql db in azure. Works fine has some data that can be replaced but, again, the point is to learn how to update model without destroying the database.
In VS2017 I add one property public string ScreenShot { get; set; }
I make some small changes to my mvc and web api controllers to handle this extra property. I update my localdb via packmanager console and add-migration addprop and update-database. Works fine, run it locally, no probs.
Goto publish, goto settings, check update database. Click publish.
It hangs for like 5 or 6 min and I get:
Warning : A project which specifies SQL Server 2016 as the target platform may experience compatibility issues with Microsoft Azure SQL Database v12. when publishing
I try publishing several times and get the same thing. Google, look around, scratch my head, try again and it seems to publish. Site opens, and somehow I have lost my bootstrap theme. In fact in my Content folder I now have 4 files i believe are new: bootstrap-theme. (css,css.map, min.css, min.css.map) (same prefix , different suffix) as well as what I think are virgin versions of those without theme in the name, and seems to be the default mvc theme of black and white.
When I goto my app and I get an generic error and checking elmah I get:
System.InvalidOperationException: The model backing the 'TaskTrackerContext'
context has changed since the database was created. Consider using Code
First Migrations to update the database (http://go.microsoft.com/fwlink/?
LinkId=238269).
Well I really thought thats what I did. Almost forgot one thing! Maybe this is where my problem lies: I actually had to run two migrations-in addition to the model change I dropped a column that had never been used (scaffolding a controller for a DTO version of one of my models added it to my context which created a table).
I did create a new branch before making any of these change so I could just revert back but at some point I have to make this work and have to understand how to do it without destroying my db and remaking fresh.
A check in SQL object explorer shows it added the ScreenShot column to my table but didn't remove the unused table.
This works for me :
In visual Studio, go to publish settings and then select the option
Execute Code First Migration
Please see the screenshots below
Kind regards
Trying to build an application that uses ASP.NET Authentication with Identity.
I've been watching a video on how to do things. They add new properties directly to the ApplicationUser class and then update the database using code-first migrations.
But I'm using database first.
So I added my new properties directly to the ApplicationUser class, and I also added compatible fields to my database. But I still get an error.
The model backing the 'ApplicationDbContext' context has changed since the database was created. Consider using Code First Migrations to update the database (http://go.microsoft.com/fwlink/?LinkId=238269).
I have Googled this and found articles specifically referencing database first, but they all seem to involve using code first!
Is this even possible to do without code first any more? Or is it just the case where we will all use code first or die?
As #Kyle suggested, this is all based on the __MigrationHistory table.
I'm not sure exactly how this all works, or what the overhead is if this table is being tested against my data each time I run my software. But renaming the table gets rid of the error. And I'm now able to modify the database as I wish without errors.
Up until now I have been using the EF Power Tools beta to do this. I click on an empty project, select EF and then reverse engineer.
The PowerTools creates all the model tables and EF mapping tables for me. It's something I do quite often when our database changes and I need to see how the mapping classes have changed. It's not completely necessary but it saves a lot of work and makes life very easy.
From what I understand is this was added to EF6.1. However where ... ?
All I see from the demos is that now I have the ability to start from a database and generate code first. For this it seems I would have to create a new application and do a lot more. I miss the two click functionality of not being able to create the mapping tables.
Does anyone know if this is still available and if I just missed it. If not available then time to go back to EF Power Tools beta :-(
Install the EF 6.1 Tools from MS downloads, and add a new "ADO.NET Entity Data Model" to your project, and you will have the new option to generate "Code First from database" https://entityframework.codeplex.com/wikipage?title=Tooling%20Consolidation
I have an application that must be accessed for many users.
To optimize the performance I intend to store each user profile information at a independant database file.
I need everytime a user login the application, to setup a new provider linked with his own database.
All databases have the same structure. So while querying user the commom generated DAL classes must switch for the database file relative the the user.
Is there a way for configure SubSonic for doing that switch at runtime?
Thanks.
Well, assuming we 're talking about SubSonic3:
I have made a patch for this and logged it as an issue in the SubSonic Templates project on github, where the source is available. You can find the issue (and a link to the code) here.
After you apply the patch, you will have a new DefaultDataProvider property which does exactly what you want. Use it like this (e.g. after a user logs in):
YourSubSonicGeneratedNamespace.YourDatabaseName.DefaultDataProvider =
SubSonic.DataProviders.ProviderFactory.GetProvider(
"your connection string here",
SubSonic.DataProviders.DbClientTypeName.SqlLite);
And you 're good to go.
For SubSonic 2, this answer sounds like what you want.
With subsonic 2 I use an approach where I inject the provider at runtime rather than loading it from the app.config file.
Look at my answer here: Subsonic in a VS2008 Add-In woes
Instead of just using one provider you could create one for every user who starts the application and change the default provider as needed.