When I try to export my SQL database through the Azure Portal, I get a 404 error (Entity not found to invoke export).
The weird thing is that a month ago it worked perfectly. I even wrote a little manual on how to do it as I exported it. A coworker found the issue when trying to do it herself.
I've seen somewhere that "the database name is case sensitive when using az sql db export". It's strange, because we have not changed anything, but I've taken a look at the activity log of the DB and compared the log for the last successful export with the failing ones and I do see that the references to de DB in the JSON of the activity log have a different case (the last "B" of the database name):
I can also see that the database name appears with different case in different places. If I go to the Database itself, the last "B" is in uppercase, but if I go to the SQL Server, it is in lowercase. If I connect to the database from SSMS, it's lowercase too. I guess its correct name is with a lowercase b...
Anyway, I'm pretty sure we haven't changed it. In fact, in the "manual" I did a month ago I can see screenshots with the same case mismatch.
Anyone knows how to fix this issue?
I think the error is happened in Azure backend, because we did nothing for the database.
We can not help you to fix the error. Only the Azure support can help you. According my experience, Azure still have some bugs for now.
Ask Azure support like this in Portal, you can follow my example:
New support request:
Basics:
Azure will give some Solutions you can reference, just click next Details, give the more details or error screenshot for Azure.
Create the request, and wait the Azure support engineer contact you with Email or Phone.
Hope this helps.
Related
Created a new SQL Server and uploaded a Bacpac file to storage. In the SQL Server area, hit the Import button, filled in the fields and the import starts. It always fails 5 mins later giving me an empty database which then has to be deleted as you can't restore an Azure DB. The Bacpac file was created with MSSMS 2016 CTP3. It couldn't connect directly to the DB server, error said "Bad request". Importing the Bacpac from within the Azure UI also results in "Bad request":-
Inner exception Microsoft.WindowsAzure.StorageClient.StorageClientException:
The value for one of the HTTP headers is not in the correct format.;
Inner exception System.Net.WebException:The remote server returned an
error: (400) Bad Request
The DB is an Umbraco website, so nothing huge or controversial I wouldn't have thought. OR is Azure down today? Getting this far has been a trial as the UI is the worst. However, if anyone can give me any advice on how to get this done I'd appreciate it.
I eventually found an article that stated the Blob Storage had to be "Classic" storage. So tried that and it all worked. The Azure UI is awful, it's too cryptic and there are far too many important things hidden by fancy widgets of limited use IMHO. Anyway, sorted now, hope this helps someone else.
Actually, I'm working on a basic ERP for a very small business. I'm using ASP.Net MVC 4 Code First and I use Windows Azure as web hoster. All is working fine on my local computer, and deployement is done without issues : website is reachable. However, my application crash whenever a database access is required, with a "very descriptive" error : "Error. An error occurred while processing the request.". There are no clue or detailled error in logs file about this error.
After digging during two days, I've understood that my database is not initialized : all tables are created, but columns aren't set. Because tables are created, I doubt it's a connection string error, but a migrations one. All tries (though Initializer class) I have done to force a database reinitialisation failed.
I searched a while on the Internet, but I saw no one having the same issue than me.
Is trhere someone who have already encoutered this case, and is there a solution to fix it ? Thanks for your answers.
PS: Sorry for english mistakes, it's not my mothertongue :)
If the database you are using is sql than you should use
SQL Database Migration Wizard for deploying on-premises sql database to windows azure. This will do the job perfectly and effortlessly.
So I posted a new blog on my site and promoted it on my facebook where the traffic spike was far bigger than anticipated, the server went down from the volume of traffic and after it was rebooted I am now getting a database connection error.
I contacted my server host and they told me this:
"I was able to get the relevant database details from the wp-config.php file in the home directory for your site and, using those creds I am able to connect to the relevant database without a problem.
To be sure that I was able to connect AND make a query to the database I have also created a simple test script that can be viewed at http://yoursite.com/mysqltest.php
This confirms that the server is responding correctly and that the database itself is able to accept connections and queries.
This leaves us with the likelihood that the issue lies with the scripting/configuration of the wordpress installation which is not something I am going to be able to assist you with.
I suspect that the problem lies with the wp-config.php file but cannot be certain."
I can't see how the wp-config would have changed, I haven't touched it in over a month and it's been working fine otherwise. The website was also working fine after I posted that blog, it was only after the server was rebooted that it doesn't. All the other sites on the server remain in perfect working condition. I don't see how a traffic spike could have done this. I'm lost as to what to do next? Please help! :(
D
Try this database connection test script https://gist.github.com/162913
I have two databases, production and stage. I am getting the error message in the title of this post when I click "Database Diagrams" for production, but on stage I don't get an error.
I've researched this message, and I've found posts such as this:
Link
They pretty much say to change the owner of my database to sa. I'm not convinced this is the issue, though, because both production and stage databases have the same owner (not sa), but I only get this error for production.
Does anyone else know how else to resolve this error message?
both production and stage databases
have the same owner (not sa), but I
only get this error for production.
That usually is the very source of the problem: a database created on one machine is restored on a different machine where the SID of the original creator is no longer valid. Change the owner to a valid one:
ALTER AUTHORIZATION ON DATABASE::[<dbname>] TO sa;
I received this error. In my case, I had existing Diagrams but could not view them on account of this error. I remembered that I had changed the name of the server a week or so ago. After renaming the computer, SQL Server (2012) apparently correctly began using the correct underlying local user object in the Logins section of Security. So, from appearances, the database had a valid owner. But the name of the security account wasn't changed - the username of the owner was correctly localputer\localuser but the SQL account name was local-puter\localuser (the original name of the server). I renamed the account name to localputer\localuser and everything went back to normal. I did not need to issue an ALTER AUTH ON DB.
Provide Used: Microsoft OLE DB Provider for SQL Server. Can anyone help me with this..
I was trying to connect with LLBLgen
This MSDN blog page has some useful on this...
http://blogs.msdn.com/sql_protocols/archive/2006/12/02/understanding-kerberos-and-ntlm-authentication-in-sql-server-connections.aspx
In my case, I found the account was locked.
Reason was I previously, on another machine more than 3 times tried to login.
It did not recognise me - and tthen finally it locked my account.
Reopening account made all work fine.
br
Jan
The error you get is almost always caused by a problem with using Windows Authentication. Please try switching to a SQL server login (username/password), or make sure your current Windows login has access to the SQL server and database you're trying to connect to.
-Edoode
I fixed this by mapping a drive to the server running MSSQL. This seemed to generate some kind of trust that allows MSSQL to connect without this error even after a reboot.
I used to get this error sometimes when connecting to my local SQL Server with Windows Authentication. I never fixed it unfortunately - it went away when I reinstalled windows.
I think a reboot used to fix it - have you tried that? Not exactly the best solution, I know :P
Try to synchronize your date and time with the your domain's. The SSPI issue may be related to Active Directory authentication problems, some of them related to date and time changes. This is very simple to check and fix. Try it out!
There is a Microsoft KB article that addresses many of the reasons for this area (KB811889) at the following URL: http://support.microsoft.com/kb/811889.
A lot of Googling shows that one of the diagnostic steps helped most people who encountered the issue.
I recently had this exact issue where I'd get this error only when authenticating with certain accounts, but not others. Ultimately what was causing my problem was not mentioned in any KB or article I found on the net, but through trial and error I discovered that when the account used through SSPI authentication to SQL Server (2k8) happened to be in a large number of groups (in my case over 250) you would get the "Cannot Generate SSPI context" error. I suspect it has something to do with overflowing the security token that Kerberos uses and have seen similar strange authentication problems for user accounts in a large number of groups.
I get the problem when I have the time set differently on my client machine than either the server or the AD machine ( I was trying to test into the future).
Short Answer: Have you recently change the user the service is running as? Was there a system crash?
Long Answer:
I know this is old, but I want to post my experience that I just had.
We had spent hours Googling and found nothing that worked.
Eventually we ran across a set of actions that could cause this:
If you change the user that the Sql Server runs as (e.g. from Local System to a domain usr) and do certain updates and the server doesn't safely reboot -- you get this.
So, we set things back to Local System and bam it worked. Swapped it to the domain user, no worky worky. Ok. Swapped it to Local System, rebooted, swapped it to domain user, rebooted, bam -- worky worky. All was good in our world. Later that morning it crapped out again... still working on that now but the priority is changing and I'm not sure we're going to continue work on this problem so I wanted to post something in case this happens to someone else.
What caused ours was we did an update and, apparently, we learned that it's bad practice to let Sql Server run as Local System so we changed it to a domain user. We never rebooted, but restart the service. A month later, we do updates. We don't reboot. A month goes by and a power strip fries causing the server to have an unexpected shutdown. Yet another month later we find out problem because we rarely connect to this particular database (Interestingly, Sql Server 2008 worked fine... it was only 2005). Or... at least this is the best we've come across.
Our admin guy doesn't like Vista and likes to blame everything on Vista (refuses to let us test Windows 7)... so he Googled "sspi vista" or something like (I know it had sspi and vista, but it might have had another one... in case you need to Google it was well) that and ran across an article that pretty explained our scenario after we had a meeting we all remember these pieces and placed this picture together.
In my case, the time synchronization issue in the Windows 2003 domain environment was actually the issue.
This was quite easy to overlook as the two had been on two different time zones, whilst showing the same times on their clocks; which in effect was about 1 hour apart.
So other than the time on their watches, check the time zones as well.