I have a database project in Visual Studio 2017. Our database project is managed just like any other library of code where multiple developers can update the project as necessary. To ease the pain of deployments, I have built a custom deployment task in our TFS 2018 (vNext) Build process that is a powershell script that calls sqlPackage.exe. SqlPackage compares our compiled database project (*.dacpac file) to our target database (in Dev, QA, etc.). I have the custom step configured so that it will write the expected changes to disk so I have a record of what was changed, then sqlPackage runs a second pass to apply the changes to the intended target database.
My DBA enabled the Query Store in our SQL 2016 Database. During my sqlPackage deployment, one of the initial steps is to turn the query store off, this makes my DBA unhappy. He wants the ability to compare pre and post deployment changes but if the query store gets turned off, we lose the history.
I have tried several of the switches in the documentation (https://msdn.microsoft.com/en-us/library/hh550080(v=vs.103).aspx#Publish%20Parameters,%20Properties,%20and%20SQLCMD%20Variables) but I can't seem to find the magic parameter.
How do I stop SqlPackage from turning off the query store?
My current script:
sqlPackage.exe /Action:Script /SourceFile: myPath\MyDatabaseName.dacpac" /OutputPath:"myPath\TheseAreMyChangesThatWillBeApplied.sql" /TargetConnectionString:"Integrated Security=true;server=MyServer;database=MyDatabase;" /p:DropObjectsNotInSource=false /p:DropPermissionsNotInSource=false /p:DropRoleMembersNotInSource=false /p:BlockOnPossibleDataLoss=True /Variables:"CrossDatabaseRefs=CrossDatabaseRefs
Is there a better way? I am surprised that I had to write a custom TFS Build Task to do this. Which makes me think that I might be doing it the hard way. (But this has worked pretty well for me for the last several years). I love database projects, I love that they enforce references and ensure that we don't break other objects when a column is dropped (for instance).
Any insight would be greatly appreciated.
Either disable the scripting of database properties using /p:ScriptDatabaseOptions=false, or update the database properties in the project to reflect the desired Query Store settings.
To set the Query Store settings in the project, right-click the database project in Solution Explorer and open Properties. From there, in the Project Settings tab find the "Database Settings..." button. In the Database Settings dialog, click the Operational tab and scroll down to find the Query Store settings.
Apparently, all we needed to do was add a post deployment script to re-enable the Query Store. Hope this helps someone out there...
USE Master
ALTER DATABASE [MyDbName] SET QUERY_STORE = ON
Related
I don't want to sound like a jerk here, but it feels like the desktop and mobile applications have been forgotten when migrations were documented.
Given:
It is unacceptable to ask an end user to run any commands to create or migrate a database.
Its not an Asp.Net Core web application so I don't have a startup.cs scaffolded.
When the software is updated on an user's device it must update its own database without user intervention the next time it runs.
This is a code first project.
I'm pretty sure its just a matter of getting the IOC container that the entity framework core code will use and putting the right things into it, but I'll be damned if I can figure out how. Despite my best google-jitsu and bing-fu, I've only been able to find docs or examples that show running using startup.cs in web projects or using the Entity Framework core CLI tools.
public void SomeDesktopAppStartupMethod()
{
var context = new DesktopAppContext();
// ??? - register some migration locator with the IOC container? ¯\(°_o)/¯
context.Database.Migrate();
// Profit!
}
Right cause there really isn't much to the migrations of your database within in a mobile. Since more than likely you are using SQLite (guessing) mobile/uwp apps don't get some of the same treatment that Web gets this is a function of MS not pushing mobile at present if you hadn't noticed. Unfortunate for most of us early adopters but early bird doesn't always get the worm.
More than likely those doing Desktop are going to be using EF not EFC and not usually target SQLite but SqlExpress or SqlLocalDb
Most of my changes for my apps are surface level changes to the database but due to limitations of the migration system you would have to write your own SQL into the UP/Down of a migration to drop columns in SQLite and the reverse to undo your changes. The is a SQLite only limitation at present, for EFC provider.
As for location in the application where I process any migrations since I am using template10 (which is in a refactoring at present) is done where the UIElement CreateRootElement(IActivatedEventArgs e) is being created. Another location to consider would be OnStartUp for the app. It would vary based the development you are doing of course XPlat might make sense where all flavors could take advantage.
Some apps when syncing data I don't bother with migrations and wipe and recreate cause its just easier from that standpoint since all data is server based on Azure.
That being said there are major changes coming from 2.0 with respect to SQLite and EFC, if read correctly there will be a heck of a lot more control over how things are "migrated" or modified from Version X.X of your app.
We're using EFCore and SQLite for our Desktop app! This is what we did for the InitialCreate migration, I can't speak to subsequent migrations, but they should be similar (solution left as exercise to the reader):
1.For the project that contains the DBContext implementation, change the csproj ItemGroup section to include
2.Right click on the project and select Open folder in File Explorer
3.Enter cmd in the command window
4.In the command window enter: dotnet ef migrations add "xxx"
where "xxx" is the name of your migration e.g. InitialCreate, or AddNewTable
5.This resulted in some error messages for me, but in the end it created a
migrations folder with 3 new classes. Date_xxx.cs Date_xxx.Designer.cs and a YourDBContextClassModelSnapshot.cs. Add the folder and classes to your project/source.
6.Ensure your DBContext implementation has an empty ctor.
7.Replace your call to context.DataBase.EnsureCreated() with
context.DataBase.Migrate()
8.Rebuild, sacrifice a few chickens, cross your fingers and hopefully the Migrate() now creates a db with version/migration info. You can edit the .DB file which is mostly binary but will have some text like the following, which does not exist when created via .EnsureCreate()
"MigrationId" TEXT NOT NULL CONSTRAINT "PK___EFMigrationsHistory" PRIMARY KEY,
"ProductVersion" TEXT NOT NULL
Notes: the first time I ran the dotnet command it failed because the EFCore designer/tools weren't loaded. I did some project rebuilds and it seemed to work after that. Also i had a lot of problems with the app during runtime getting "EFCore assembly failing to load" crashes due to different projects referencing different versions. Took many clean/rebuilds to get this working again once the .csprojs were tweaked to ref the same version. Also, out of curiosity i tried The "ef migrations remove" command, but it failed to execute (unable to load Sqlite3), fortunately we don't need to use that cmd yet.
In SAP Crystal Server Java BI Launch Pad inside Documents > Folders > Public Folders I've created a new folder and imported (many many) reports to it.
Don't know what happened to the server but all of it's settings have been reset, and the folder is no longer there - so I need to recreate it, and import all my reports back (a proccess that takes a long time since I need to import one report at a time).
Is there a way to backup/export that folder as a backup? so next time a thing like this happens I can just restore my folder with all the reports from that backup file?
Thanks
You can use Promotion Management (aka LifeCycle Management or LCM as it was known in previous iterations) to export any set of objects (documents, universes, …). You can access this (web) application via the CMC.
Instead of live-to-live promotion (i.e. from one live system to another live system), you'd choose for a live-to-BIAR promotion, where the selected content would be exported to an .lcmbiar file. An .lcmbiar file is basically a ZIP archive which consists of the actual objects (e.g. reports, …) as you would find them on the FRS share as well as metadata information.
To restore an .lcmbiar file, you'd upload it back to the server through Promotion Management.
Alternatively, you could use the CLI to generate the file, without having to go through the web interface. This is especially useful if your promotion job consists of a very large (100+) number of objects or the selection criteria are quite specific.
You can find more information on Promotion Management in Business Intelligence Platform Administrator Guide, chapter 15.
I have a serious problem that needs to be resolved.
In my server explorer in VS2013, I set up a connection to the database with valid user and password credentials.
So I have a schema called: Connect1, and it needs to have access to another schema called Connect2, both under the same data source name: Dev1. The user I'm connecting with is called Connect1, so by default I'm connected to the schema Connect1. I was able to verify that I have access permissions for this user to connect to Connect2.
Using ODP.NET Managed Driver, I was able to set this up. Putting all the connection details.
Configurations are shown in this page:
Using Oracle Developer Tools for Visual Studio
In order to allow the schemas to be viewed, I had to change the Filters tab, and add all the related schemas I'm using (adding Connect2). Then I click update, and I'm able to use the tables into my edmx file.
However, the problem occurs when I close Visual Studios. My filter gets lost, and my connection is back to using only Connect1.
This then destroys my table mapping in my edmx file with a series of
Error 11007: Entity type 'Table1' is not mapped
This is really frustrating as I'd have to keep on repeating the same procedure over and over again manually remapping all my tables.
What's confusing is when I update the data connection from my Server Explorer to include the second schema.. EF works and detects the tables; but my app config and the connection string has not been changed. So this leads me to believe that if I was to promote my project to production or test, that it will break since there's nothing in my project to show that Connect2 is needed.
Okay I realize the big pitfall that was never explained properly. I highly urge people to follow this if you ever want to use EF with Oracle and you're using another schema.
The pitfall is that since we introduced oracle's schema convention to the EDMX, there was no way of knowing how volatile the mappings would become. The reason why this was never a problem for microsoft is because there is no such thing as a schema in SQL server. To implement two databases in the same edmx file, there is some visible prevention that inhibits you from adding any tables whatsoever. After we introduce schemas, it becomes very fragile.
So what you have to do is follow the steps of adding the schema (as I explained in the question). Going to Filter tab, adding the schemas that way, and clicking the Update button.
Once that is applied to the server explorer, the edmx will have access to adding the tables from that schema. When you do, the EDMX has recollection of the schema embedded in its file. So if you ever do close visual studios, and reopen and run the project, it will still work.
Here are the few tips you want to AVOID:
Do not rename any of the entities and the columns (properties), even though it makes your code more readable. That's the first uh-oh. Since the mappings are very volatile, if you happen to mess up, remapping everything back again will be a chore.
The second uh-oh, is when you close Visual Studios, reopen it again, forget to reinclude your schema in Server Explorer, go to the edmx and do "Update model from database" to include anything else (but most importantly.. EVEN IF YOU DON'T DO ANYTHING) and you click OK, your model will still update regardless of non-changes, lose all the mappings that you previously made. That is what I mean by the maps being volatile.
In case that happens, and you didn't do the first uh-oh of renaming entities or the properties.. is to delete all your entities already there, and re-add them again.
The reason why you want to delete all the entities is because adding new ones with the same name will add a new entity with the same name + a number. So something like entity of Customer will still be there, adding the entity again will create a new entity called Customer1.
Sigh.
I am using Enterprise Library 5.0 configuration tool from within VS2010.
Every time I open it, it keeps showing the following 2 settings even though I do not use them at all.
Application Settings
Database Settings
Its very annoying. How do I stop these 2 settings from showing up from within the configuration-tool unless I am actually using them.
Thanks
The database settings are there because there are database connection strings in machine.config. The way the .NET config system works, they show up when you enumerate sections.
AppSettings are there because just about every app does use appsettings, and so it was felt to be a convenience to include them. Note that this isn't an entlib section, it's the default .NET one.
There's no way to get them to stop showing up in the tool as written, you'd have to change the code of the config tool to change this behavior.
We are using Scott Hansleman's suggestion for multiple web.configs from his post here. The problem we have is that we have to check out the Web.Config. If we remove it from the project, when we publish, no web.config is pushed. So we need to remove the source control bindings just from the web.config, but leave it in the project, and have the rest of the project still held under source control.
The issue is that source control makes the file read only until you check it out. We need to be able ot overwrite it with the prebuild events, preferably without having to check it out. Is there a way to remove the bindings from that file only, and still leave it as part of the project?
Thanks.
By adding a new file to solution explorer, you will get the little plus sign indicating it is due to be added to source control. Then, right-click and choose "undo pending changes". This will cancel the add but leave the file in your project.
If that doesn't work I suggest one of the following methods:
Use the Attrib task from the MSBuild
Community Tasks project to remove
the read only flag.
Use the Exec
task in MSBuild to invoke
tf.exe and checkout the file.
You should leave the file in source control. Otherwise you'll run into several issues:
changes won't be versioned. 'nuf said.
it can't be branched or merged, even though web.config is one of the files that's most likely to vary between parallel dev/test/production environments
changes you make locally won't propagate to coworkers without manual workarounds
developers setting up an environment for the first time won't get the file at all
Team Builds won't contain the file, so neither will your deployments. (surely you're not deploying directly from the desktop?!)
Note that the state of individual files is stored entirely on the TFS server. ('tf properties' dumps this metadata if you're curious) Only projects & solutions have bindings actually written into the file. And even those are dummy entries that tell VS "don't worry about me, just ask TFSProvider, it'll know who I am and where I'm supposed to be." While there are many other quirks in the VS project system that give me endless headaches, in this case it's your friend. Don't circumvent it.
Best options:
Edit your build script to toggle the read-only attribute before/after modification. If you're using the "copyifnewer.bat" script from the linked blog post, it should literally be one extra line. Even if you want to keep things entirely declarative within the MSBuild makefile, it's barely any work with the help of 3rd party tasks.
Use the File -> Source Control -> Exclude feature. After applying this setting, the file remains under source control, but will no longer be subject to automatic checkouts/checkins by the active solution. In other words, you can edit the file locally to your heart's content without affecting anyone else, but if you want to commit (or shelve) your changes you'll need to do it from Source Control Explorer or the command line.
Option #1 has the advantage of being a very quick fix for your existing setup. The downside comes from maintaining several copies of web.config.* Same reason why copy/pasting code is bad: if you change one, you have to go change all the others -- or worse, forget and let them drift out of sync until strange bugs force you to revisit the issue. This could be improved by changing the process so that there's only 1 "master" web.config and the additional copies only contain differences (via a textual diff engine, XSLT transforms, programmatic manipulation in Powershell, etc). Of course, that's more work.
Option #2 avoids #1's problems with very little overhead. (the engineering process itself is unchanged; only difference is how the Visual Studio UI behaves) This advantage is critical if you make changes to web.config at all frequently. Downside is that there is no built-in way to track variations on the "master" file. If the only diffs are dirt simple, eg a connection string or two, you may find it easiest to stick with just one "master" and let people make ad hoc changes on their dev machines. There are even tools to do this for you, such as Web Deployment Projects (easy) and the IIS Deployment Tool (complex). In any case your actual deployment should be automated and source-controlled, of course! If heavier customizations are required than these tools are capable of, then you'll probably want the hybrid master + transform approach described earlier.
I recently ran into the issue and could not find a good solution. With a little trial and error I was able to figure this out myself.
This works on Visual Studio 2015. I tried to follow the answer above, but 2015 does not have an "Exclude From Source Control Option" I could find. It does have source control / project integration where if you delete the file from source control or the project, it will automatically be removed from both places. This integration is enforced when you have the solution containing the project open.
The problem is when using a web.template.config, web.config is really a build output and should not be in source control. However deleting the file entirely and removing it from the project causes problems because then the file is not part of the Build / Publish steps.
So the work around turns out to be simple:
Close the solution. File --> Close Solution.
In the Source Control Explorer Window, Delete the file.
Check in the Change.
Open your solution and you will see that the Config file remains in the project.
You may see the Triangle / Exclamation Mark Icon warning showing the the config file is not found.
Rebuild the project and click on the file.
The file should now show without the warning.
It should not have the padlock icon next to it. This indicates that it is not under version control.
I did some more checking and found the "Exclude From source Control" feature. The key is that you need to select the item in the Solution Explorer window before selecting the menu item:
Select the Web.config file in the "Solution Explorer".
In the menus select File -> source control -> advanced -> Exclude Web.config from Source Control.
You will now get a Red Circle / White Line icon.
This works if the file is NOT ALREADY in source control.
If the file IS ALREADY in source control you need to do the procedure above to remove it from source control without also deleting it from the project.