Ok, I do not know why Elmah is not logging any errors while deployed on Windows Azure. Another thing is that it used to work before. The environment is the same.
using SqlErrorLog on Sql Azure
Sql Azure sharing the same database as the main site. I did not use a separate database so I can use the same connection string.
building off the source and I've excluded the VistaDB and SQLite dlls.
I've checked my web.config settings and have the handler and module defined under system.webServer. It seems to log messages alright under local development (webdev.exe) and the local sql express schema was exported to an sql azure schema (including the stored procs).
The only difference is that on the main site, the app is running under a main domain with multiple subdomains. Locally this is simulated by modifying the host file. Logs ok locally but not when deployed.
Any ideas on what I should do to find out what's wrong? Last option is using diagnostics to trace/find out what's wrong while it's deployed but that's a pita.
It turns out that the table Elmah_Error was created with a non-clustered primary key which is not supported by Sql Azure.
It seems that the SSMS 2008 R2 Nov CTP still exports nonclustered PK as nonclustered PKs even when you specify the target as SQL Azure. :(
Related
I have a question regarding asp.NET Core and Azure SQL Database
We can successfully connect to Azure SQL DB via the localhost or VS Debug. I used the same Publish connection string to update the appsettings.json "DefaultConnection". We continue to get an error on Azure URL when trying to login or register. It is not able to connect to the same Azure SQL database successfully.
Also, we get the standard error, which is set correctly in the config files.
Error. An error occurred while processing your request. Development Mode Swapping to Development environment will display more detailed information about the error that occurred. Development environment should not be enabled in deployed applications, as it can result in sensitive information from exceptions being displayed to end users. For local debugging, development environment can be enabled by setting the ASPNETCORE_ENVIRONMENT environment variable to Development, and restarting the application.
Not sure what the issue is with Azure connecting to the database...any help appreciated. To recap, it works with the Azure SQL DB from local host, and the DefaultConnection is the same for both versions.
If I recall correctly, the Azure Web Apps do a bit of work under the covers to make it possible to change the connection string from the portal; as a result, it may complicate the process you attempted to use with "publish", as it may not update the key-value pairs that it stores the connection string as. AFAIK, updating/publishing again will update the code, but not the existing values that are in the key-value store.
This is detailed here: how connection strings work in Azure Web Apps
I have a web app published on Azure.(created locally via visual studio)
I ve also migrated my main Database(Azure Sql database) and connected with the web app and of cource already created an sql server instance.
My problem is with my local db file .mdf file in my App_Data folder.
When i published my app returned error below:
provider: SQL Network Interfaces, error: 52 - Unable to locate a LocalDB installation. Verify that SQL Server Express is properly installed and that the LocalDB feature is enabled.
How to attach .mdf file ? and associated it with my sql server instance?
Thanks
I think you can't use SQL Server Express (pretty sure there is no Express installed). Why do you want to use SQL Server Express?
Anyway, you can migrate it to Azure into SQL Server Compact - http://www.asp.net/mvc/overview/older-versions/deployment-to-a-hosting-provider/deployment-to-a-hosting-provider-deploying-sql-server-compact-databases-2-of-12
But that way is not very efficient if you plan to implement any type of replication - any instance will have own db - and some other drawbacks.
I believe that the best way here is to use SQL Azure and migrate your data into it if there is no need in something like SQL Server Compact/Express.
I am using Visual Studio Community 2013, SQL Server 2008 R2 Express Edition for an MVC web application using entity framework code first migrations for my database.
I am trying to get my local application hosted on the Microsoft Azure platform.
I have registered for a trial account which expires in 30 days, and deployed my MVC5 app out which has been successful.
However, this app requires a database which I am struggling to deploy.
What is the easiest way to get my database deployed out to Azure as I do not seem to have the :
"Tasks" -> "Deploy Database to Microsoft Azure SQL Database" option available to me in SSMS.
I have extracted a Data-tier Application of my local database and have it stored on my C drive, however if I connect to my Azure Account in a second window, and right click the server then select Deploy Data-tier Application, it fails on "Creating schema object in database" with the following error:
TITLE: Microsoft SQL Server Management Studio
An exception occurred while executing a Transact-SQL statement or
batch. (Microsoft.SqlServer.ConnectionInfo)
------------------------------ ADDITIONAL INFORMATION:
Users cannot be mapped to certificates, asymmetric keys, or Windows
logins in this version of SQL Server. (Microsoft SQL Server, Error:
40528)
I'm assuming its tried to create my local account plus the IIS APPPOOL account I had to set up to host the website on my local network, however I do not see a way of removing them from the .dacpac export.
When I refresh the Databases node, there is still no database, I'm fairly lost now as to how I might get my db deployed to this server?
If you can extract a compatible Data-tier application and then Deploy it to your target server using your current version of Management studio, then this approach should work, see this link for more reading on ensuring your database is compatible.
Failing this, as was in my case. I downloaded Management Studio 2015, which gave me the option to deploy database to Azure by simply right clicking the required database.
Again, this threw up the error regarding my database level IISAPPOOL user, but not my server account user. As a way around this, I took a backup/restore of the database and removed this user then deployed the copy database obviously minus the problem account.
Now all that was left to do was add a transform to my Release web.config with the Azure connection string as provided on the Azure dashboard, and re-deploy the website.
Problem solved.
I am experimenting with EF7 beta 4 in combination with Azure web apps. Strangely:
1. A local web server / local db setup works;
2. A local web server / azure db setup works;
3. But: the Azure web server with azure db setup does not work. This results in the following infamous exception:
InvalidOperationException: There is already an open DataReader associated with this Command which must be closed first.
The connectionstring I use is as follows (currently the same on local web server and Azure web server):
Server=...database.windows.net,1433;Database=...;User ID=...;Password=...;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;MultipleActiveResultSets=true
What do I have to do to get it running?
I had exactly the same problem when using Azure SQL Database.
My web.config files had the same flag in relevant connection strings. Everything worked fine locally but it didn't work when I published my solution into azure as web app.
MultipleActiveResultSets=true
The reason is that web.config files might be overwritten in your publishing profile. You need to add that setting explicitly like below:
I have two visual studio 2010 projects that I am running locally. One is a cloud project and connects to azure table (development) storage in addition to a local SQL Express, the other is not a cloud project. Both projects attempt to connect to a local SQL Express database via similar code generated through an xsd as well as directly in an aspx via a databound grid. The non-cloud project connects fine, but the cloud project fails with the common error:
"An attempt to attach an auto-named database for file C:\Users...mdf failed. A database with the same name exists, or specified file cannot be opened, or it is located on UNC share."
Both projects use the same connection string in a Web.config file:
<add name="WorkoutLogConnectionString1"
connectionString="Data Source=.\SQLEXPRESS;AttachDbFilename=C:\Users\...mdf;
Integrated Security=True;User Instance=True" providerName="System.Data.SqlClient" />
In VS2010 server explorer from the cloud project I can connect to the express database just fine, but when the project runs, it fails to connect. The cloud project also connects to a SQL Azure remote cloud database via another connection string in Web.config and that connection works fine.
I saw the MS support article: http://support.microsoft.com/kb/2002980 and thought that maybe the projects were originally created with different versions of VS and that maybe causing my issues, so I made the suggested IIS changes to the ASP.net 4.0 application pools, but to no avail.
Since the SQL Express connection string works in one project and not in the other I am stumped. Are there some other configuration elements or something related to the failing project being a cloud project that I should be looking at?
Are you tyring to run both the project simultaneously (at the same time - multiple startup projects). If so, it is indeed common issue with SQL Express. Often happens also when you have opened the database in your VS Server Explorer. If you have multiple applications accessing the same database, I suggest that you manually attach the database in your SQL Server Express. You can do by:
open SSMS (Sql Server Management Studio), connecting to your local SQL Express instance.
Navigate to Databases branch
Right click -> Attach Database
Browse to your mdf file
Done!
Now change your connection to the one suggested by Aaron. Generally I advice to now use the AttachDbFilename and UserInstance, but instead attach the database directly and use it as with a regular stand-alone instance of SQL Server. Saves lots of headaches.
Have you attached your database to an actual SQL Server Express instance? If so, remove all that AttachDbFilename and User Instance nonsense. To keep things simple and consistent you could probably use SQL Authenication locally. So you should just have something like:
<add name="WorkoutLogConnectionString1"
connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=DatabaseName;
User ID=SQLAuthUsername;Password=password" providerName="System.Data.SqlClient" />