I'm using Entity Framework with a code first model; I've got my InitialCreate migration setup and working locally, I can run code against my database context, and everything works.
But when I deploy my project to Azure, I just get a connection string error ("Format of the initialization string does not conform to specification starting at index 0.").
I can't seem to find where in the Publish dialog are the options to create the Azure database. -- Do I have to create the database separately and hook them up manually? -- If so, what exact process should I follow. Does the database need to have contents?
I thought Microsoft was making a big deal that this could all be done in a single deploy step, but that doesn't seem to be the case from my current experience.
When you publish your project in the publish dialog, there is an option for the code first migration in the Settings tab, it will automatically show your data context and it will give you the option to set the remote connection string, and this will add a section in web.config to specify the data context and the Migration class to run during the migration process.
It will also allow you to set if you want to run the code first Migration or not.
You can also take a backup from the dev and clear the data then upload it to Azure SQL DB, this way the code first data context will check at first connection and it will find the code an database the same
Related
Just created a simple ASP.NET MvC project, to list blood pressure measurements. I opted to use SQLite as a database as it is (supposedly) embedded into the project, therefore eliminating the need for an external database. Which is expensive, and the reason why I chose to go with SQLite. That way I would only need to host the web app, which is free, if I chose the free tier, F1.
Publishing through VS2022 is successful, and the app shows correctly, except it shows none of the measurements. Which renders the app ((no) pun intended) useless, at least as a cloud app. I have done some research, and changed the publishingsettings a couple of times, but this is how they look right now.
Configuration: Release
Target Framework: net6.0
Deployment Mode: Self-contained
Target Runtime: win-x86
File Publish Options: None of the options chosen
Databases: Default Connection - Use this connection string at runtime:
=> Data source=bloodpressuremeasurements.db
Entity Framework Migrations: BloodPressureContext (name of the DbContext)
- Apply this migration on publish: NOT chosen, since it gave me an exception and publish failed
Site Extension Options: Install ASP.NET Core Logging Integration Site Extension
- NOT chosen
I also tried changing the option for the db file to Copy To Output Directory: Copy always.
That didn't change a thing. What am I missing?
The website works now as intended, with all the data shown. It looks like the problem stems from scaffolding read and write methods, which made Visual Studio 2022 pull in EntityFrameworkCore.SqlServer. Which is not what I wanted, since I'm using SQLite.
That in turn created some service dependencies under Connected Services, one of them being SQL Server something. It also appeared under the Publish menu, and seems to have caused the compilator to view the connection string as an SQL Server database connection.
I created a new app, and copied the code from the first one. I was careful not to scaffold, as I only need a Get method, to show all measurements. I need none of the other methods in CRUD, neither Post, Delete, nor Update. I will add new measurements by running the app again locally, and read the measurements from a CSV file (did that in the beginning). Then I will publish the app anew, with the updated SQLite database.
I currently have an ASP.NET Core 2.0 project and I've just implemented code first migrations to the localdb and have around 3 migrations including the initial create. I'm wondering what the correct process is to change to a new database? Is it simply a case of updating the connection string and running the below in the project directory?
dotnet ef database update
My current knowledge is based on the below Microsoft tutorial and I've been using the CLI commands.
https://learn.microsoft.com/en-us/aspnet/core/data/ef-mvc/migrations
In answer to my own question, it does appear that running the following command in the existing project directory will build a new database from scratch including all the existing migrations. As long as you update the connection string to the new database and have already implemented migrations on the existing database.
dotnet ef database update
correct process is to change to a new database
Everything depends what you mean by writing this sentence ( I am not sure what "new database" means in it) altough flow looks like this:
1. First you make initial create
2. Then you change something in your code (create some additional fields etc)
3. Then you write "dotnet ef database update" command in CLI to update your current database.
I have added a new default ASP.NET 5 web app, and chosen to deploy to AZURE. This works fine, but if I retry and add a azure sql db, then I get the error below as it tries to create the new resource group.
Microsoft Visual Studio
Template deployment failed. Deployment operation statuses:
Failed: /subscriptions/81368473107b/resourceGroups/DJWTestDb/providers/Microsoft.Sql/servers/djwtestdbdbserver ()
error (InvalidApiVersionParameter): The api-version '2.0' is invalid. The api version must be of the following format: yyyy-MM-dd. This format supports the following suffixes: '-preview,-alpha,-beta,-rc,-privatepreview'.
Succeeded: /subscriptions/81368473107b/resourceGroups/DJWTestDb/providers/Microsoft.Web/serverfarms/DJWTestDbPlan ()
I've been running into the same problem, just registered to let you know. It seems that it isn't possible right now (who knows why, but I'm looking at you, ASP.NET RC1) to publish while deploying an SQL server. However, it DOES work to publish without one and make one in the portal, and then connect them through your Web.config.
At first I thought it was all of the new updates to Visual Studio (as of 5/12/15), but I was still getting the same problems after updating. I'm not sure if the new updates are required for this workaround, but that's what I was working with for this.
Steps:
1. Publish your API app as normal, without including an SQL server.
2. Go to your Azure portal and navigate to the "SQL Databases" tab.
3. Create a new database using your existing server, or just make a new database server if you don't have one yet.
4. When it's done (it may take a second for it to show up in the list), click on the new database and it's settings will appear. You want to go to the "Show Database Connection Strings" option.
5. Save the ADO.NET connection string!
6. Go back to your project in Visual Studio and navigate to the Web.config file.
7. In the "connectionStrings" header, find your database context. It should have a name formatted like YOURDATABASENAMEContext, or something similar. It'll probably be the second entry there. Replace (save a copy first, see note below for why) the inside of the "connectionString" with the ADO.NET connection string of the database you just created.
8. Publish and it should work!
NOTE: This workaround, if followed literally, means the program won't function locally anymore (e.g. starting the app rather than publishing it) since it will be looking for that database in the connection strings. You could return it to it's original state for testing, and then use the azure connection string when publishing, although I'm sure there's a more elegant way to do it.
While regular publish to Azure with WebDeploy, had checked Execute Code First Migrations, which i did before.
But this time the Use this connection string at runtime, was also checked, and i published without noticing it. as a result the remote azure db was wiped and instead is seeded with what looks like a default database with aspnetmemembership tables and _Migrations table that only has migrations related to identity tables.
The production data w db structures is gone and I did not yet setup backup on azure, doing it now.
Is there way to restore the database from some sort of auto backup on azure, i have web version w 1Gb size selected, I do not see any options
this suggests that web version would not have any daily backup, but also that web version is discountinued as of april, but i still have it. http://msdn.microsoft.com/en-us/library/jj650016.aspx
and another questions, i understand everything that happened? But it seems extremly dangerous that its so easy to wipe out the whole database and VS shows no warning nor publishing to azure notifies of anything. Is there anything that can be done to prevent dumb but yet very costly erros like this ?
TIA
I'm a building an internal webb application for components of building parts. I have table with projects which is tied to some other tables. When a user creates a new project, I want to "bootstrap" the project with a default categorization schema, which the user then can modify for his/her project. So I need to do some copy from a default schema and tie it to the users project.
I'm running NodeJS on backend, AngularJS on frontend and postgres as db. Where is the best way to put this logic? Either I use triggers on the db. The trigger is activated when a new post is made to the project table. Or, I'll do it with complicated queries in Node. Or is there some other way? Is there a best practice? It's probably "easier" to do a trigger. But I worry about the maintenance and testing of the app.
Since the issue that you have is related to the state of the database, you should solve it inside the database. There are basically two ways of solving this:
Revoke the insert privilege on the project table. Create a function new_project() that has parameters for all the required initial state of the project. Inside that function you create schema, do some copying, setup privileges and populate the tables with the parameter values.
Revoke the insert privilege on the project table. Create a view that has all required columns from all relevant tables to make a valid initial project and create an INSTEAD OF INSERT trigger on the views. In the trigger function you perform all the required steps as above.
Debugging code on PostgreSQL is not very advanced but whether or not you place you code in PostgreSQL or on the application side, you will have the same issues. The advantage of PostgreSQL is that the bug - if any - is never far away from where you code operates.