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.
Related
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.
I have an application (.NET WPF LinqtoSQL) that works when I connect to a local database. When I changed to a database on a different server I get an error (SQL Server Instance not found error 26).
The solutions to this error are all based on the server, firewall, and making sure SQL Server Browser is up and running, none of which I can do because I have no rights on the server.
But I created a small test application using WPF and EF (ADO.NET) that successfully connects to the exact same database (and table). I have no clue what might be going on, but I am not sure I want to re-write the application using EF (at least right now).
Does anyone understand the difference between the framesworks' connection method to point me to a possible solution for the LinqToSQL version beyond waiting for the IT guys to "fix" the server?
Given the revelation above that EF and L2S use the same connection class I figured a new project that points to the new server would fix my issue. And it did:
I created a new project, added a new L2S item, and then copied in all of my old projects views/ viewmodels/ etc. and it runs just fine.
I thought I could simply update the connection string, as this is what I believe I have done successfully in the past, but perhaps there is something else had to be set somewhere in the project settings or generated DataContext code to the new server. If anyone knows what that is please answer and I'll accept it.
I came over this serious problem.
My WordPress website was running all right. suddenly It showed the page of WordPress installation. so, I quickly registered a user and so on. Then it showed "db connection error". I went to my server and tried to log into my phpmyadmin but the password didn't work. This kept happening for 5 mins. then thing worked normal again.
1- is this a hacker attack?
2- how do I prevent the page of WP installation from showing up if the db connection goes down again? because this is a desaster
how do I prevent wp-admin from showing the name of my db in the db connection error ? Better preventing any error report from my website when anything is down?
thanks
Nobody can tell you whether it was hacker related without a lot more information. There should be logs on the machine hosting your site--I would check them first to see if you can tell if the database went down and why. If you don't admin your own site you can ask your hosting provider what the problem was--they may have been rebooting a database machine, for example.
I would also do a full backup of your site and database in case there is any hardware trouble you don't know about.
In the meantime, if you administer the site yourself, take a look at advice for hardening Wordpress: http://codex.wordpress.org/Hardening_WordPress
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.
Occasionally, on a ASP (classic) site users will get this error:
[DBNETLIB][ConnectionRead (recv()).]General network error.
Seems to be random and not connected to any particular page. The SQL server is separated from the web server and my guess is that every once and a while the "link" goes down between the two. Router/switch issue... or has someone else ran into this problem before?
Using the same setup as yours (ie separate web and database server), I've seen it from time to time and it has always been a connection problem between the servers - typically when the database server is being rebooted but sometimes when there's a comms problem somewhere in the system. I've not seen it triggered by any problems with the ASP code itself, which is why you're seeing it apparently at random and not connected to a particular page.
I'd seen this error many times. It could be caused by many things including network errors too :).
But one of the reason could be built-in feature of MS-SQL.
The feature detects DoS attacks -- in this case too many request from web server :).
But I have no idea how we fixed it :(.
SQL server configuration Manager
Disable TCP/IP , Enable Shared Memory & Named Pipes
Good Luck !
Not a solution exactly and not the same environment. However I get this error in a VBA/Excel program, and the problem is I have a hanging transaction which has not been submitted in SQL Server Management Studio (SSMS). After closing SSMS, everything works. So the lesson is a hanging transaction can block sprocs from proceeding (obvious fact, I know!). Hope this help someone here.
open command prompt - Run as administrator and type following command on the client side
netsh advfirewall set allprofiles state off
FWIW, I had this error from Excel, which would hang on an EXEC which worked fine within SSMS. I've seen queries with problems before, which were also OK within SSMS, due to 'parameter sniffing' and unsuitable cached query plans. Making a minor edit to the SP cured the problem, and it worked OK afterwards in its orginal form. I'd be interested to hear if anyone has encountered this scenario too. Try the good old OPTION (OPTIMIZE FOR UNKNOWN) :)