I know this question has been asked many times, but none of the symptoms seem to match my problem and thus none of the solutions work.
I am in the process of moving a DNN site (v. 7.04) from our company's IT infrastructure to an externally hosted VM as they were unable to give guaranteed up time. (The last straw was when their DNS server fell over Friday afternoon and we couldn't even contact anyone until Monday morning. Still took them two more days to fix it, but I digress...)
I'm administering the VM so I have full access to it and the software running on it. I do not have access to the server on which the website and database are currently running.
I have copied the website files from the old server to the new and have been provided with database backups which I have successfully restored on the new VM. The new VM is running IIS 8.5, SQL Express 2014 and Windows Server 2012 R2 Datacenter. I have set up the website in IIS and given read/write permissions to NETWORK SERVICE and IIS_IUSRS. The web.config file can be read as if I type something silly I get a syntax error showing the correct line.
Now here is where things diverge from the trivial (for me at least). I can connect to the database (on the local machine) using Management Studio, HeidiSQL and the Data Link Properties dialog (see https://www.sophos.com/en-us/support/knowledgebase/65525.aspx). All three of those work fine. When I put the connection string into the web.config, I get the can't connect error. The precise message is "DNN Error Connection To The Database Failed".
Here's the connection string I'm using, it's nothing special and is what the production server is currently using, though with a different data source of course:
Data Source=[machine]\[instance];Initial Catalog=[database]; User ID=[user];Password=[password];
I'm guessing it's not the database itself since that seems to be fine and I can connect to it as mentioned, so I'm thinking maybe something in IIS?
Any help would be appreciated.
Related
We've had this .NET component (.exe) running to migrate documents between 2 databases for almost a year. Console app is using the System.Data.SqlTypes.SqlFileStream .NET class to read/write from file system.
After a recent upgrade of SQL Server to SQL Server 2016 (SP2-CU3) (KB4458871) - 13.0.5216.0 (X64) - the console app has stopped working and throws the following error when trying to open specific document for read operation:
System.ComponentModel.Win32Exception (0x80004005): The device is not ready
We double-checked FILESTREAM properties on both databases to make sure they are enabled (just in case they were removed somehow during the upgrade) and we confirmed they are configured as needed.
We are running out of troubleshooting options as we don't know what to check for. All ports seem to be open between the app server where this tool runs and the database servers (same as before).
Let me know if anybody has any idea what could have changed after recent SQL Server upgrade.
just in case someone faces the same issue... we were able to resolve this by actually disabling FILESTREAM, rebooting servers, enabling FILESTREAM back on.
Issue was related to some un-mapped path of physical drives for SQL (sorry i cant provide more details)
I recently inhereted a DNN site that has went down as of yesterday (I made no changes to it).
On the front end I see the error
500 - Internal server error.
There is a problem with the resource you are looking for, and it cannot be displayed."
I looked at the logs in /Portals/_default/Logs and I see
"2018-08-21 05:57:01,024 [WEBA9][Thread:37][ERROR] DotNetNuke.Common.Initialize - The connection to the database has failed, however, the application is already completely installed, a 500 error page will be shown to visitors"
Does anyone know how I could begin to start debugging this? I'm completely new to DNN. Thanks!
You'll want to start by looking at your web.config file in the root of the site.
From there you'll find the connection string. (control-F to search)
Using the Connection information in that connection string, you should try
Try remoting into the database server to see if you can access it via Remote Desktop, can you access it? Does that server need rebooting?
Try connecting to the database using SSMS (SQL Server Management Studio) using the username/pwd in the connection string.
I imagine that the SQL server is for some reason offline, and you'll need to get it back up and running.
It can happen after a reboot of the server. When IIS with the DNN site comes online earlier than the SQL server is done loading.
Stopping and starting the AppPool of the DNN installation might help.
I'm in the midst of moving my company's timekeeping system from an old, slow Access backend to a snappy and quick SQL Server backend. What I'm finding though, is that while the frontend has no problem connecting to the backend on my machine or a handful of others, on most of the machines here, it just doesn't seem to work at all.
I'm linking tables using the CreateTableDef method, found here. An AutoExec macro establishes the tables at start-up. On my machine, running Windows 7 Professional 64-bit with Access 2016 (Version 1801, Build 9001.2171), it opens up with no issues. Another, rather disparate machine out in the shop, running Windows XP 32-bit with the Access 2010 Database runtime engine (this machine does not have a full version of Office, only the runtime) also works without a problem.
Other computers here in the office, however, running the same version of Office, with Windows 7 or 10, always 64-bit & Professional, when opening the .mdb file, fail to connect to SQL Server.
In one case, Access will hang for up to 30 minutes, before spitting out
ODBC--connection to '(server name here)' failed.
I've tried running a server profiler while Access is attempting to establish a connection, and what I'm seeing is that the server apparently isn't seeing the connection attempt, at all. This particular machine also runs a separate utility written in VC# to connect to and manipulate the database, which runs without a hitch. Only in the Access frontend, do I encounter problems.
So, in summary:
Microsoft SQL Server backend
Access frontend
Access frontend has no problems connecting on some machines, fails to connect on other machines.
Separate utility written in VC# works fine everywhere it's tried, including machines where the Access frontend doesn't work.
Profiler trace on server doesn't show any connection attempt being made by machines where the Access frontend doesn't seem to work.
I've tried installing the Access Database Engine, I've tried installing SSMS on one machine (no dice), I've installed as many different ODBC drivers from Microsoft as I can find, but nothing seems to make a difference. I'm inclined to think that the problem is not the driver, but some kind of network-related issue, and somehow specific to Access.
Any ideas? Is there some arcane software requirement that I'm just not aware of?
So, I found this thread, where someone has having trouble connecting on a first attempt. Turns out that this is a firewall issue. By nailing down the port the SQL Server instance is using, and explicitly opening it in the firewall, all connection issues apparently go away. Why it worked without issue on some computers, I still have no idea, but after making this change, everything does what it's supposed to.
Okay, these are the errors I can't backtrace at all. So I was hoping you had any idea.
When I recently rebooted my server (The server is a home computer, and just runs Windows 7 as a development machine) with Sharepoint 2010, a whole list of problems occurred.
The major error was that when I deployed my Visual Studio 2010 project, it couldn't activate my Feature. This happens more often, because I sometimes mess up in my Feature Activation event handler. But, when that happens, I can access the site, and debug the error while activating the feature manually.
However, this time, things were different. My site didn't even want to start up? So I checked IIS Manager, and it said that the site was stopped. Manually starting it resulted in the following error:
The process cannot access the file because it is being used by another process. (Exception from HRESULT: 0x80070020)
I have no clue what that could mean? What file? The web.config? I really don't know.
But I saw that the Sharepoint Central Administration was running, so I decided to check there. However, this resulted in even more errors, well, there was one, but it really frightened me:
Cannot connect to the configuration database.
So, not only my Web server is having errors, but also my database server. Time to check the event logs is what I thought.
And there I'm a bit stunned. There are so many errors, I don't even know where to start. I'm just going to copy the ones which I think are important.
Unknown SQL Exception -1 occurred. Additional error information from SQL Server is included below.
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)
Sharepoint Foundation seems to give me that one.
The World Wide Web Publishing Service (WWW Service) did not register the URL prefix http://*:80/ for site 908852174. The site has been disabled. The data field contains the error number.
IIS-W3SVC seems to give me that one.
I.. really have no clue what could be the case. Since I cannot acces Central Administration, I can't check for any health issues either.
Anyone has even the slightest idea? I didn't do anything funny I believe. I was thinking that it could've been the updates that were installed, but the only updates installed were:
Security Update for Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package (KB973923)
Definition Update for Microsoft Security Essentials - KB972696 (Definition 1.93.855.0)
Definition Update for Microsoft Security Essentials - KB972696 (Definition 1.93.1040.0)
Definition Update for Microsoft Security Essentials - KB972696 (Definition 1.93.1148.0)
So, it really couldn't have been that. I'm out of ideas, and I really would like to solve this.
Thanks,
Mats
EDIT: Okay, manually started up the SQL Service, and now Central Administration works. But, The Health reporting site started scaring me. There's a list of 8 items requiring my attention.
NT AUTHORITY\NETWORK SERVICE, the account used for the SharePoint timer service and the central administration site, is highly privileged and should not be used for any other services on any machines in the server farm. The following services were found to use this account: SharePoint - 80 (Application Pool)
SPUserCodeV4(Windows Service)
OSearch14(Windows Service)
Web Analytics Data Processing Service(Windows Service)
All required products must be installed on all servers in the farm, and all products should have the same patching and upgrade level across the farm.
Upgrade is required on server MATS-PC. Without the upgrade, the server is not in a supported state.
The following databases have versions that are older than the current SharePoint software, but are within the backwards compatible range:
SharePoint_Config_c5681991-3bec-45b3-9376-ea8c19c51b6a,
SharePoint_AdminContent_39d0c8e9-214e-42b9-909e-ffbe4147208b,
WSS_Content,
WSS_Search_MATS-PC,
WSS_Logging.
Those seemed to be the most relevant. Hm. I have no clue? Especially about the upgrading? I didn't upgrade anything recently.
Especially about the upgrading? I didn't upgrade anything recently.
This sounds a lot like a Microsoft Update. Service packs for SQL Server come through Microsoft Update, and if you applied those without checking carefully, some of them produce similar symptoms to what you're describing. SQL Server can take longer to start up, and when that happens, sometimes antivirus software grabs the MDF/LDF files for scanning. That will cause the databases to be unavailable, and other services will then fail on startup.
When you started SQL manually, things started working again, but now you've got version dependency problems. You're lucky SQL even starts, though - I've had clients with issues where SQL won't start after careless SP applications if they had changed the SA login, for example.
The errors you got while doing the reboot where just because the SQL Service did not startup. No database = no SharePoint. This happens to me all the time.
The other messages in Central Administration are nothing to do with your SQL startup and chances are they have been there for some time.
As any other developer on a single box hosting SharePoint, you have permissioned stuff with a single powerful account. Central Admin now detects this and gives you the warning.
It looks like the SharePoint versions of one or more of your server databases are out of sync with the version of 2010? Not exactly sure how it got into this state, but for a dev box I would not be completely stressed. An upgrade to the new service pack hopefully would sort this out.
Relevant background-
I'm a noob working my brains out for over a year into trying to make a database in MS SQL Server 2008 Express with the end idea for the front end being Access. After tons of reading and slaving over my schemas and three major revisions I'm finally ready to connect it to Access and I'm just striking out all around. The Microsoft Access IN and OUT book says it has instructions for this but they're on the included cd in the bonus material which seems to be the only part of the cd that will not work. Everything I've found on the internet hasn't gotten me there. The best I think I've found was an answer on this site but even the list of things to do given as the answer have me hitting some walls that I just haven't the foggiest of how to get through.
I'm going to lay these out and mention what I have and haven't done with each.
Just for background I'm running Access 2007 on a Vista machine that I'm pretty sure is up to date on the service packs (I should have 7 in a few days, it's in the mail finally) and I'm running SQL Server 2008 Express with the management studio.
Here's the answer that I was referencing--
The answer was given by the user "Renaud Bompuis" at the following link
Connect Access 2007 to SQL Server 2008 Database
There should be no issue with connecting Access 2007 to a SQL Server 2008 database.
You need to make sure that:
1.
Your SQL Server 2008 database is accessible, ie that it isn't locked down and that it is accessible to the machine(s) where you will have your Access 2007 application.
A few things to check:
* In SQL Server 2008, go to Properties > Connections > Check "Allow remote connections to this server".
I checked and the check box is checked to allow remote connections. Since this is on the same machine I don't know if this is vital, but whether or not it is it's taken care of to the best of my understanding.
* Enable TCP/IP in the Configuration Manager.
didn't think this was necessary since it's on the same machine but I did it all the same.
* Make sure the firewall allows incoming connections on TCP port 1433.
This is one thing I didn't do since I really couldn't see how a firewall would get in the way if both instances (the SQL Server Express and Access 2007) are on the same machine under the same admin login. But if I'm wrong on this please tell me how to go about altering things.
* You can also start the SQL Server Browser Service so your SQL Server instance can be found.
Did this, even restarted the machine, still can't get Access, nor the ODBC, to pull up the SQL Server 2008 instance on the machine. Nothing.
2.
You have created an ODBC DSN (a System DSN) using Windows ODBC administration tool. If you're running on a 64 bit system, make sure that you're using the 32 bit version of ODBC to create your DSN, otherwise it will never be visible to Access which is a 32 bits application.
Went in there to make the system DSN and when I choose the SQL Server Native Client 10 thing and go to hit the drop down menu to choose the data source it pauses and then nothing comes up, nothing to choose from at all.
3.
Once you have created the ODBC link (and tested it works) on the machine where Access is installed, you can just link the tables: In Access 2007, in the External Data ribbon tab > import > More > ODBC Database.
Then select the DSN you create for your SQL Server 2008 database and chose which tables you want to link.
So clearly this last part I can't even try since I can't even get an ODBC link.
I have a feeling, being a self taught noob and all, that I'm probably missing something obvious to a professional or seasoned amateur but regardless of what my problem is it's driving me nuts. Having a good portion of the last year of my life put into this I'd really like to be able to make progress finally on the front end so that I can finally get some utility out of all my effort beyond just writing queries in SSMS.
Thanks in advance for any and all help anyone can give.
OK, so you're obviously having trouble creating the DSN. Have you tried using "SQL Server" or "SQL Native Client" instead of "SQL Server Native Client 10.0" as the driver? I've found a webpage with a few screenshots on creating an SQL Server DSN (scroll down to the section "Creating a ODBC DSN"), maybe they can give you some guidance.
If it all fails, could you provide a screenshot of the part of the DSN creation process where you get stuck?
I appreciate all yer'allz help. Even though I didn't really see much new and nothing directly helped me I did end up looking in the SQL Server Configuration Manager and the 'VIA' (whatever that means) was the only thing I hadn't enabled (since I hadn't read anything about it in all my investigations--I usually shy away from making modifications to settings that I don't have someone specifically telling me to modify) I hadn't previously touched it nor thought much of anything about the fact that it was the only thing I'd yet to enable.
Well I enabled it, restared services and YAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHOOOOOOOOOOOOOOOOOOOO!!!!!!!!!!!!
I'm now able to (and have successfully) created a ODBC DSN AND I've got Access connected to my database!!!!
I like this site!
Thank you all for caring and for presenting me stuff that led, however fumblingly, to a solution!
Be glad we are only connected through the internet otherwise I'd kiss ya!