I have a simple windows service that we have used for years. We developed it in-house, but no one has touched it for years. It updates a couple tables in a SQL database located on the same server. I installed it on a virtual server, and it appears to be running, but is not updating the SQL database.
I believe it connects to the database using an Alias set up in CLICONFG. It is set using a Named Pipes connection pointing to the local SQL EXPRESS database.
It is running properly on a server with a default instance of SQL EXPRESS installed. The only difference I can find is this current server has a Named Instance (.\SQLEXPRESS). However, I have had it running successfully on other servers with a Named instance rather than a default instance, but I can't seem to get this one to work.
I have searched and searched and have been unable to figure out what is wrong.
I've checked for possible permissions issues in SQL, and everything seems to be in order with the login I have chosen for the service.
Thanks!
Thanks everyone for your suggestions. I figured it out!
Turns out it was connecting to SQL through a Named Pipes Connection setup in cliconfg.
I already had a Named Pipes Connection setup with our standard alias....and the pipe specifying the SQL Named Instance....that wasn't working for this server.
The service was expecting a default instance. The service had worked properly before w/a Named Instance w/out modifying our standard Named Pipes configuration, but that was a 32-bit windows server. This time, on a 64-bit windows server, it wasn't working.
So....
I used ProcMon to determine what it was looking for...then added a second Named Pipes connection named "(local)" instead of our standard alias. I set the pipe up exactly the same as our other connection. I left our standard Named Pipes Connection there as well with our standard alias.
Rebooted and it worked!
Related
In my job we have several servers with SQL Servers. Every one has several instances. Access to any was clear... until today. I wrote app in WPF which use connection string as this
Data Source=server02\system; Initial Catalog=*****; User Id=*****; Password=*****;
Under every * hides char [a-zA-Z], digit or special char.
When I run my app from my coputer location everything works, but if I run it from server02 location (//server02/apps/app.exe) it fails.
Exception:
SQL Network Interfaces, error: 26 – Error Locating Server/Instance Specified
And the question is... How to fix it? Why the hell server connected to our LAN doesn't recognize his own localdb?!
Enable Named Pipes connections from your SQL Server instance.
For this just go to SQL Server Configuration Manager to enable Named Pipes.
We have a purchased commercial app that accesses a named, locally installed SQL server instance.
Is there any way for us to transparently move the DB to a remote shared SQL Server host, but still have things configured within SQL Server so that the local software can access as it it were a local instance?
Keep in mind, since it's a purchased software package, I don't have the ability to modify the queries it's running, so if tables have to change into fully qualified, or other special T-SQL syntax to make this work, it's not an option.
Effectively, we need to "trick" the app to use a remote database, but access as if it's a local instance (though configuration, some sort of proxy, or perhaps dark magic).
The total extent of the application DB configuration settings is to select the name of the local instance to connect, as shown in this image: .
SQL server is installed on the local machine (Win2012R2x64), and has a couple instances running. I have complete control of both local & remote SQL servers, so can make unrestricted config changes to them. Current DB version is SQL2014, but could upgrade to newer if newer version features are needed to do this.
You can try creating an alias to the remote sqlserver from the local sql server. (Via Sql Server Configuration Manager | Aliases | Add a new Alias name)
Your local instance alias should be the name server name that the connection string is using to connect.
I've used this method in the past to change the sql instance that I was connecting to without changing any connection string info.
More info here
It depends what sort of access the commercial app needs in the locally installed database once the app has set up and created its database.
You will probably invalidate any support agreements in the attempt. Worse still, if a commercial app insists on a local instance then I dread to think what security horrors it will insist upon in your shared instance.
You need to profile the database while the functionality of the application is used to find out what it does and how it does it. Even if you determine that the security permissions could be greatly restricted you may find that the app checks to see if it has a higher permission level.
I've no way to hand of testing this approach but....
Install the app as usual which will be on your local instance
Back up the DB on your local instance and restore the DB to your remote instance. Remember to set up what logins are necessary.
Set up a linked server to on your local instance to your remote instance.
Delete all objects in your local DB instance
Create sysnonyms for all objects pointing at the remote instance.
If it is an application that simply requires direct table access this might work. It is however an ABOMINATION.
I have migrated a classic ASP site to a new server and am getting the following error, message.
I have tried different connection strings but none of them work.
I am not even sure if the connection string is the problem
The new server is a Windows 2012 Server, SQL Server 2008 R2 Express machine.
Microsoft OLE DB Provider for SQL Server error '80004005'
[DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.
/scripts/dbcode.asp, line 31
Application("C2M_ConnectionString") = "Provider=SQLNCLI10;Server=(local);Database=mysite_live;Uid=mysitec_Live;Pwd=mypass;"
If it is an Express instance, it is most likely not a default instance, but rather a named instance. So you probably meant:
... "Provider=SQLNCLI10;Server=.\SQLEXPRESS; ...
--- instead of just (local) ---^^^^^^^^^^^^
Otherwise you'll need to show us the server properties in SQL Server Configuration Manager on that machine in order for us to be able to tell you how to correct your connection string.
As Aaron Bertrand mentioned it would be interesting to have a look at your connection properties (In Sql Server configuration check if the following are enabled Name Pipes and TCP/Ip).
Since you're able to connect from SSMS i would ask to check if the Remote connection is allowed on that server Also can you tell is the Sql browser service is running?
here is a link that i keep close to me as a reminder or check list on probable connection issues on SQL Server.
Sql Connection Issues
And lastly can you try as provider "SQLNCLI" instead of "SQLNCLI10"
Step-1: Enabling TCP/IP Protocol
Start >> All Programs >> Microsoft SQL Server >> Configuration Tools >> SQL Server Configuration Manager >> SQL Server Network Configuration >> Protocols for MSSQLSERVER >> right click “TCP/IP” and select “Enable”.
Step-2: change specific machine name in Data Source attributes'value to (local) will resovle the problem ni SQL SERVER 2012.
Try pinging the server in your connection string. The server your application resides on should be able to communicate on the port you specify by credentials. If you are developing locally try specifying "localhost". If the server is clustered or you installed as an instance then you need to specify that instance. Also make sure the server is configured for mixed-mode authentication if using sql credentials.
OR Try
Data Source=localhost;Initial Catalog=DBNAME;Persist Security Info=True;User ID=MyUserName; Password=MyPassword;
It can be a permission issue , Please check is that server is connecting with same configuration detail from SQL management.
other is username / password is wrong.
Here is what I would do:
EDIT: Note that this SO post, a few down, has an interesting method for creating the correct connection string to use.
Open SSMS (Sql Server Management Studio) and copy/paste the
username/password. Don't type them, copy/paste. Verify there isn't
an issue.
Fire up the code (this is next for me b/c this would be the next
easiest thing to do in my case) and step to line 31 to verify that
everything is setup properly. Here is some info on how to do
this. I understand that this may be impossible for you with this
being on production so you might skip this step. If at all possible
though, I'd set this up on my local machine and verify that there is
no issue connecting locally. If I get this error locally, then I
have a better chance at fixing it.
Verify that Provider=SQLNCLI10 is installed on the production
server. I would follow this SO post, probably the answer posted
by gbn.
You have other working websites? Are any of them classic asp? Even
if not, I'd compare the connection string in another site to the one
that you are using here. Make sure there are no obvious differences.
Fire up SQL Server Profiler and start tracing. Connect to the site
and cause the error then go to profiler and see if it gives you an
additional error information.
If all of that fails, I would start going through this.
Sorry I can't just point to something and say, there's the problem!
Good luck!
Have you ever tried SQL Server OLE DB driver connection string:
"Provider=sqloledb;Data Source=(local);Initial Catalog=mysite_live;User Id=mysitec_Live;Password=mypass;"
or ODBC driver:
"Driver={SQL Server};Server=SERVERNAME;Trusted_Connection=no;Database=mysite_live;Uid=mysitec_Live;Pwd=mypass;"
At least this is what I would do if nothing helps. Maybe you will be able to get more useful error information.
Could this be a x86/x64 thing?
The following thread seems to indicate that the (local) alias is a 32-bit alias which fails on 64-bit server:
http://social.msdn.microsoft.com/Forums/en-US/sqldataaccess/thread/c701d510-90e5-4dd0-b14f-ca1d694d6615
(note that the error is exacly what you had)
When you were testing the .udl on the server did you test both x86 and x64?
Following the advice from this blogpost (http://blogs.msdn.com/b/farukcelik/archive/2007/12/31/udl-test-on-a-64-bit-machine.aspx) you could test your
local udl :
in 64-bit by just double clicking it (acts the same as running "C:\Program Files\Common Files\System\Ole DB\oledb32.dll",OpenDSLFile C:\\test.udl
in 32-bit by double running C:\Windows\syswow64\rundll32.exe "C:\Program Files (x86)\Common Files\System\Ole DB\oledb32.dll",OpenDSLFile C:\\test.udl
If you can confirm it's a problem with the alias I'd suggest you create a new one by following the guidelines found here:
http://msdn.microsoft.com/en-us/library/ms190445(v=sql.105).aspx
Have you tried to use the server IP address instead of the "(local)"?
Something like "Server=192.168.1.1;" (clearly you need to use the real IP address of your server)
In case you try to use the server IP address, check in the "SQL-Server configurator" that SQL Server is listening on the IP address you use in your connection. (SQL Server Configurator screenshot)
Other useful thing to check / try:
And check also if the DB is in the default SQL Server instance, or if it is in a named instance.
Do you have checked if the firewall have the TCP/IP rule for opening the port of you SQL Server?
Have you tried to connect to SQL Server using other software that use the TCP/IP connection?
The SQL Server Browser service is disabled by default on installation. I'd recommend that you enable and start it. For more information, see this link and the section titled "Using SQL Server Browser" for an explanation of why this might be your problem.
If you don't wish to enable the service, you can enable TCP/IP protocol (it's disabled by default), specify a static port number, and use 127.0.01,<port number> to identify the server.
In line 31:
cmd.ActiveConnection = Application("C2M_ConnectionString")
How are you instantiating cmd?
Rather than the ConnectionString being wrong, maybe cmd is acting differently in the new environment.
Edited to add:
I see that you've gone from IIS 7 to IIS 8. To run Classic ASP sites on IIS 7 required manual changes to server defaults, such as "allow parent paths." Is it possible that some of the needed tweaks didn't get migrated over?
If you're not running with Option Strict On, you should try that - it often reveals the source of subtle problems like this. (Of course, first you'll be forced to declare all your variables, which is very tedious with finished code.)
I am having a hell of a time trying to connect to the SQL SERVER 2005 database. I am using Windows 7.
Here is the screenshot of the error thrown:
(source: highoncoding.com)
I have been battling this issue for the past week and still no progress.
I have tried the following in the server name:
(local)
localhost
computername
none of them worked!
I just checked in the services section and SQLSERVER EXPRESS is not even there. I am using the following post as a reference:
https://serverfault.com/questions/11745/i-cannot-connect-to-my-local-sql-server-2008
This instance of SQL Server is running on the same PC you're connecting from? That's the implication of 'local'.
Possibilities :
1) Try (local) instead of local for the server name
2) Try 'MSSQLSERVER' as the name
3) Check the SQL Server Configuration Manager shows the same configuration options you're attempting to connect with, eg the same instance name, Named Pipes enabled, services running ok, etc.
EDIT :
Ok, what are you using to connect with? SQL Server Management Studio Express? Are you sure you installed an instance? The lack of SQLExpress in the services list would seem to indicate otherwise.
When you connect to a SQL Server you specify the name in the form {computername}\{instancename}. The {instancename} is the name of the SQL instance which was chosen during the SQL Server installation. For {computername} you can substitute the special names . or local when connecting to the localhost machine. If the SQL Server was installed as the Default instance then the instance name part must be omitted, so the connection Server name becomes just the computer name.
SQL Server Express installs by default an instance named SQLEXPRESS. The corresponding NT service name is MSSQL$SQLEXPRESS. The Server name in the connection dialog is .\SQLEXPRESS, local\SQLEXPRESS, localhost\SQLEXPRESS or {computername}\SQLEXPRESS (they're all the same).
If the SQL Server was installed as the Default instance name then the corresponding NT service name is MSSQLSERVER. The Server name in the connection dialog is ., local, localhost or {computername} (they're all the same).
If the SQL Server was installed as a named instance then the corresponding NT service name is MSSQL${INSTANCENAME}. The Server name in the connection dialog is .\{INSTANCENAME}, local\{INSTANCENAME}, localhost\{INSTANCENAME} or {computername}\{INSTANCENAME} (they're all the same).
When connecting from a remote computer to a SQL Server instance the SQL has to be configured to allow remote connection How to configure SQL Server 2005 to allow remote connections.
Check your SQL server configuration, make sure the TCP connections are enabled. You can also check that the SQL Browser service is started. Make sure you do not have a firewall that gets on the way. Make sure the SQL Server service is also started.
Did you install SQL Server on the default instance, or have you used named instances? If you've used named instances then the server will be server\instancename. If you don't know, then have a look in the Services administrative tool; you'll be able to determine the instance name, if any, from there).
You could also try connecting with the server name as a single period (i.e. simply ".") [caveat... I've not got access to SQL Server at the moment, but I think I've used this before now].
When setting up a system that requires a remote computer to access SQL 2008 stored on another computer in the same domain, I'm running into the following error:
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.
When I installed SQL Server, I was sure I set up the system just so. How can I troubleshoot this?
I appreciate this thread is old now and already has an accepted answer, but I found a slightly different solution with regards to this issue that others may find useful. From reading this issue description I found that there were two SQL Server services in the standard Windows Local Services control panel: MSSQLSERVER and SQLEXPRESS (see below).
I found that SQLEXPRESS was running, but MSSQLSERVER was not. So I simply started that service, and I was able to connect to SQL Server again.
A couple of things to try...
check the Configuration settings to ensure that the TCP protocol is enabled.
try accessing the remote server via IP instead of the server name, this has worked for me in the past (oddly).
I'm assuming its running on the default port, if it isnt then you will need to specify the port number after the server-name / ip separated by a comma:
sql-server-name,{port}
Look at the name of the SQL server instance and make sure it is what you are using to connect to it. Also, look at the SQL Server Network Configuration under Configuration Tools. I worte an article about a very similar problem (if not the same) here:
Having had this a few times even with named pipes the first thing I always try is pre-pending the server name before the named instance; so SERVER\namedinstance. You can manually overwrite the dropdown values in the connect . So ideally in the setup it should have a brief tip below the named instance box like Enter SERVER\namedinstance. Although knowing MS if you entered this you'd probably end up with SERVER\SERVER\namedinstance...!
You can also use the browse option (bottom of server dropdown) and if you're lucky it may be in the 2nd tab (Network Servers) - even if it's a local install.
The program you are running needs to be running under an account which has access to the network (and depending on protocol chosen, may need access to the SQL Server by role or whatever). This error indicates that it is not finding the server on the network by name or IP.
The most common case I have seen this is when you have a web app running under a local account which does not have network access attempting to access SQL Server on another machine.
If you have access to the server that SQL Server is running on, you can try:
-Opening SQL Server Configuration Manager
-In the left pane, click 'SQL Server Network Configuration' and then 'Protocols for [instance name, possibly SQLEXPRESS]'
-Right click TCP/IP again and you'll see the port used. Mine was listed under IPAll/TCP Dynamic Port.
-In SQL Server Management studio add the port name to your connection string as follows:
if you were connecting to:
MYSERVER\SQLEXPRESS
the port is specified as
MYSERVER,2071\SQLEXPRESS