I am hoping to get some input on a configuration challenge I am having with a connection string connecting to a named SQL server instance when DNS resolution is not available.
What I have is a third party application that gets a connection string injected into a web.config file via a configuration utility. The configuration uses the server-name\instance-name format to connect to SQL server.
However, the server itself does not have the ability to resolve the name via DNS so it will not work. I can get the database connection working by using the IP address and unfortunately I cannot change the instance name that gets pushed to the web.config file.
I am trying to avoid having this break and need to be manually adjusted any time the configuration gets pushed.
What I am hoping to do is utilize the hosts file to get the connection working properly, but maybe there is another solution.
The database is a named instance, but is using the default port so in my hosts file I am able to add this:
Server-IP Server-Name
and then in my web.config use just the server name server-name in the connection string data source to make a connection.
However, the configuration will always push the data source as server-name\instance-name so I need to somehow get that additional instance name working in my local resolution.
I did try in the hosts file:
Server-Ip Server-Name\Instance-Name
but that did not work. Also server-name\instance-name in the connection string does not work with just the server-name in the hosts file.
As a reference all of the following will work in the connection string without anything in the hosts file:
Server-IP
Server-IP,Port
Server-IP,Port\InstanceName
but the only thing I can get working is server-name only in the hosts file and connection string.
As indicated by AlwaysLearning in the comments, the solution was to allow udp/1434 access for SSRP queries.
Related
When I use getrange against a server the URIs all show localhost.
Is this normal?
I get a communication error when I go forward and want to eliminate this rather basic item.
Thanks in advance
Greg
The public address on the server needs to get set to the correct network address. The default seems to be localhost, so any links generated by the server will only work when opened on the server itself.
You can change the public network address in the MYOB API config file. That should be located on the server at C:\Program Files (x86)\MYOB\API\2.x.x.x\. The xml config file should be called MYOB.AccountRight.API.WindowsServiceHost.exe.config.
In the config file, under <appSettings> there should be a PublicAddressServer key. Update the corresponding value with the correct network address or DNS name for the server.
Lastly, restart the MYOB API service for the changes to take effect. The Windows service name should be MYOB AccountRight API Service.
Give that a try and see if it helps!
Edit: Source - http://myobapi.tumblr.com/post/70231017169/how-to-change-config-variables-for-the-desktop-api
I have a local SQL Server DB on my domain-attached machine to which I'm trying to connect via a WPF app. The original connstring was:
Server=MyMachine.MyDomain.local;Database=MyDomain;Trusted_Connection=True
That resulted in a failed connection (could connect via SSMS just fine), access is denied. When I changed the connstring to:
Server=MyMachine;Database=MyDomain;Trusted_Connection=True
everything connected properly. Any thoughts as to why? It's not a big deal, as it's a test db, but I'd like to understand.
It's a guess, but I'd bet that name resolution is failing. Somehow the dns lookup is failing, but the short name works because it tries a netbios lookup instead of a dns lookup. It likely also works if you put in the server IP address.
I finally found the problem: protocol TCP/IP was disabled, so it appears that calling it via MyMachine.MyDomain.local was trying to use the TCP/IP protocol, even though it was on my local machine.
I am locally running an Oracle 11g database. I have a small program connecting to it in code via OLEDB in VC++ (It only runs some database tests, I'm making sure I have all the basics down before I go into the real thing.) The connection information in code only includes the provider, instance name, user name, and password. All this aspect works fine.
//For example, both these ways of connecting work:
result = dataSource.Open(DATABASE_PROVIDER, DATABASE_NAME,
DATABASE_USER_NAME, DATABASE_USER_PASSWORD);
result = dataSource.OpenFromInitializationString(L"Provider=OraOLEDB.OracleDataSource=orcl;User ID=SYSTEM;Password=admin;");
I now want to send this program to other computers in my network and run it from there, connecting to my database on my local machine.
How would I go about connecting the other computers to my database in a way that the code will understand?
I have been trying to connect locally via IP instead of "localhost", figuring I could then simply use the same code and client. In that regard, I have tried a few things without success:
-I have tried modifying the connection string to change "Data Source" to my IP, but it could not connect.
-I have tried adding some parameters from other connection string examples I had seen, but they were not for Oracle and were ignored.
-I have also tried modifying tnsnames.ora and listener.ora to change local host to an IP address, but I know that didn't work, as it would still connect if I entered rubbish.
Anyone has the knowledge to help out?
For an Oracle db, you should set up a new tnsnames entry on their individual machines that points to your local db. Then use that new tns name as the datasource. You'll also need to make sure that your local db instance is accessible to them in the first place. (This is not enabled by default in Oracle Express, by the way.)
I've also generally had more success using msdaora as the data provider instead of OraOLEDB.
I'm trying to build a connection string for a test environment that will connect to the local SQL Server instance on different machines. The purpose of this is so that a developer can checkout the code from TFS, build it, and run the testcases, connecting to his local DB. The problem is that different developer's machines may have different SQL Server setups. In particular, some may be running the full server, others may be running SQL Server Express.
I'm trying to right a utility routine that will take template connection string (e.g., Data Source=(local); Initial Catalog= myDB; Integrated Security=SSPI;) and modify the Data Source to work with the local server.
I've tried using SmoApplication.EnumAvailableServers() (returns an empty table, regardless of whether I user true or false parameters), and SqlDataSourceEnumerator.GetDataSources() (returns 2888 servers from the network, but none on the local machine), SQLCMD -L (returns nothing).
Any suggestions?
In the alternative, is there an easy way to tell whether a particular connection string will connect to a server (without waiting for it to timeout if it doesn't). If I could find the answer to that, I could try the likely suspects until I got one to work.
you might try to get the connection string as following:
Create a new blank file and name it test.udl.
Double click on it, and a "Data Link Properties" dialog should appear.
On "Providers" tab, select "Microsoft OLE DB Provider for SQL Server" or "SQL Native Client"
On "Connections" tab, try various settings and use the "Test Connection" button to test them. Click "Ok" when it works.
Open the test.udl file in Notepad and copy the line that starts with "Provider=" into your Web.config "ConnectionString" value, BUT delete the little part that says "Provider=SQLNCLI.1;"
If you want each developer to work with their own local SQL server, then the ADO connection string should have the Data Source set to localhost
... ; Data Source=localhost; ...
Additionally, to get a list of current servers, go to the command line and run
osql -L
You can look in the registry to find all local SQL Server instances. This key contains the list: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL.
Each named instance will have a value in this key. For named instances the name of the value is the same as the name of the instance. For the default instance the value will be named MSSQLSERVER.
This will do the trick:
Data Source=.\SQLEXPRESS
I have a legacy VB6 app where the servername, databasename, username, etc are defined in an INI file, but the port number for the connection string (the default 1433) is hard coded in the app. It's being moved to a new sql server back end that runs off a different port number. I'm trying to avoid having to alter and recompile the application which entails signifigant retesting, documentation, etc. I tried altering the INI file so that for the new server I have put in: SERVERNAME\INSTANCE,NEWPORTNUMBER
This effectively builds the connection with Data Source = SERVERNAME\INSTANCE,NEWPORTNUMBER,1433;
This appears to work correctly as it connects to the database when I run the app. It appears to me that the ,1433 portion is being ignored. Is this a valid assumption or will this cause me some problem I'm not seeing here?
EDIT: The string way the connection string is built in the VB6 code is:
ConnectString = "Provider=MSDataShape;Trusted_Connection=Yes;Data Source=" & SERVER & ",1433;Initial Catalog=" & DATABASE & ";Data Provider=SQLOLEDB.1;Extended Properties=""Network=DBMSSOCN"""
with the SERVER & DATABASE values pulled from the INI file.
Port 1433 would normally override the INSTANCENAME. (MS blog Reference and another)
3 options I see:
The instance name is being ignored, and you're connecting to the default instance on port 1433
The named instance listens on port 1433
You have a client alias (not convinced about this one)
Can we see the code that creates the connection string?
Is there a network reason you need to use TCP/IP to connect to sql server?
My guess is that you just need to include a ; after the servername/instance name and just leave the port number out altogether. This will cause the port number to be extraneous data in the connection string. Which I think is just ignored. You can test creating an connection string yourself by creating a test.udl file and double clicking it - follow the wizard. After your done the connection string is in the udl file which you can view with notepad.
And of course if you are looking for the syntax for connection strings, you can look them up on connectionstrings.com
Download a free HEX editor
Save a copy of your original exe somewhere
safe
Open the exe in the HEX editor
Find the 1433 and change it to your
new port number
Once it works, you don't have to retest everything (like you would on a recompile)
If the new port number is not four digits it is trickier (path of least resistance: change it to a four digit port)
I have changed connection strings this way in the past.
A VB6 exe always uses DBCS so you may have to play with the hex editor until you figure out how to use the search feature in the right way.
If the port number is stored as an integer it may be trickier to find, but still possible (look for strings near it for your clues).
Apparently this app is quickly hacked together. Try to hack it back with a simple connect-string-injection like SERVER="{your_server},{your_port};FooBar="
I'm not sure that every library that uses the connection string would necessarily parse it the same way. I would think there could be one library that parses that connection string and just drops off the last port number and another that throws an error for an invalid port number perhaps. What libraries are using that connection string?
If you're using integrated security, then maybe you could set the Data Source in the INI file to say,
SERVERNAME,PORT; Password=
and let the SQL server ignore the Password key, which is unused with integrated security. That is if the code that constructs the connection string doesn't check for stuff like that. Oh, Will Rickards said this already also it seems.