Azure Website Keeps Trying to Connect to Old Database - azure

For some reason, when I published my site to Azure from Visual Studio, it created a new DB. My DB was named something like MySiteDB and it created a database called mysite_db. I finally found the issue in the publish settings and changed it so that it pointed to the right database. I then deleted the old database since it was essentially empty. However, it's still trying to connect to the old database (that is, mysite_db). Where else could this be set? I've searched the entire solution for mysite_db and it's nowhere to be found.

Related

Powerapps to Azure SQL Server connection sudden error Bad Data source Inner exception, Not a valid data Source

I've been working with Powerapps for about 3 to 4 months now, and this particular app I've created connects to 3 tables in an Azure SQL Server Database. It's been working great until today. This morning I logged in to edit a feature on the app and my galleries were empty with an error message saying: "Bad Data source Inner exception, Not a valid data Source".
My first thought was, something is off on the database, some planned work possibly during the night, but that's not the case, and the DB is working perfectly as I also use it in PowerBI.
I googled for the error and found several people with a similar issue, and most of them reported that deleting the Data Source connections from power apps and adding them again would fix the issue, as well as deleting and creating the Galleries again. I've performed both actions, and the same error returns. I tried creating a fresh new canvas app, with a gallery and a brand new connection to the Azure Sql DB and still got the same error. I've also tried to restore one of the oldest versions of the app, and I still got the same error. This to me all indicates there's a problem with the DB, but...when I publish the APP, and run the app after publishing, It works perfectly, and I have full usability of the app, which means the connection to the DB is actually working.
It feels like a bug to me. I'll share the screenshot of the error:
Error Message
I'm worried I will lose all my work, so if someone could help me, that would be great.
Finally, I got the solution for this issue. This are the steps I followed to solve the issue.
Remove all the Database connectors from your app.
Go to File -> Settings -> Advanced Settings -> Disable enhanced Microsoft SQL Server Connector.
Add all your Database connectors back again.

SQLITE_BUSY Azure read-only issue with Node.js

I'm trying to get my React/Node/Express app deployed to Azure and everything is working so far except I cannot write to the sqlite3 database. Whenever a function attempts to write the logs show the following error:
SQLITE_BUSY: database is locked
I suspect that the .sqlite file is read-only, but have no idea how to change this. Any help greatly appreaciated!
It appears that the issue here was the default way that Azure/VS Code deploys is into a read-only wwwroot folder. In the end I abandoned sqlite and converted everything to Azure SQL DB and working flawlessly, but was a fair bit of work to transition.

ASP.NET 5 Azure template deployment failed creating SQL Server

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.

Publish to Azure from Vs2013 with 'Execute Code First Migrations' checked overwrote remote database

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

Published mvc4 web application re-seeding/erasing db randomly

I have created a website using mvc4, everything working fine in the dev environment.
The site was running for about 6 hours (luckily only a few people had registered) and then the database reverted to the state it would be when the site was first published.
I had made a few changed to the site since it had gone live (just to the views) and those changes persisted, had the site somehow re-published itself, those changes wouldn't have stayed.
The changes I made as to how the db seeds were all from this post; http://kevin-junghans.blogspot.ie/2013/01/seeding-customizing-aspnet-mvc.html .
Any help would be great, I can't pin down the problem and don't want to put the site live again until I know that user accounts won't be deleted.
If there is any more specific information that would be useful for identifying the problem let me know.
I ended up publishing the project including the database, than removing reference to initDb and recreating the database, then re-publishing.. And so far the issue hasn't happened again.

Resources