I have created a connection and fetching data using the method given in the code section.
Now I want a way where I take the database and server name as input from the user and save it to the same connection string i.e. "ConnString" in this case in the App.Config file. Also I need a way to check whether the new server name and database name are correctly provided by the user(I mean it makes a successfull connection). Please help.
private Database _db = EnterpriseLibraryContainer.Current.GetInstance<Database>("ConnString");
Enterprise Library doesn't do anything along these lines. To change the connection string section in the config file, you'll need to go through the ConfigurationManager class to get the ConnectionStringsSection and modify that. Depending on your environment and security settings you may not have permissions to write to the config file, though, so be warned.
Validating the server name and database name will require writing some database specific code - I'm not sure exactly off the top of my head how / if it's done.
Related
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.
I am trying to connect Jmeter to a geo redundant database with two hosts and I am struggling with finding the right Database Url format.
This is how my connection string looks like:
jdbc:oracle:thin:#(DESCRIPTION=(ENABLE=BROKEN)(FAILOVER=on)(CONNECT_TIMEOUT=5sec)(TRANSPORT_CONNECT_TIMEOUT=3sec)(RETRY_COUNT=3)(LOAD_BALANCE=on)(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=HostName)(PORT=port)))(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=HostName2)(PORT=port)))(CONNECT_DATA=(SERVICE_NAME=ServiceName)))
Database Connection Configuration is as following:
JDBC Driver Class: oracle.jdbc.OracleDriver Username: username
Password: password
For the Database URL I tried different formats and I keep getting the error:
Cannot load JDBC driver class 'oracle.jdbc.OracleDriver'
Note that the ojdbc.jar file is in the /lib folder as per the Jmeter documentation. Also, the ports are the same for both hosts.
Any suggestion is welcome. :)
I don't think you will be able to establish the connection to Oracle RAC using JMeter's JDBC Connection Configuration as it doesn't allow full flexibility therefore you will not be able to properly instantiate the PoolDataSourceFactory
So I would recommend switching to JSR223 Test Elements and Groovy language where you will have the full freedom when it comes to setting up the connection, executing queries, accessing results, etc. The relevant code would be something like:
def prop = new Properties()
prop.put('oracle.jdbc.thinForceDNSLoadBalancing','true')
PoolDataSource pds = PoolDataSourceFactory.getPoolDataSource()
pds.setConnectionProperties(prop)
pds.setConnectionFactoryClassName('oracle.jdbc.pool.OracleDataSource'); pds.setUser('johndoe')
pds.setPassword('secret')
String dbURL =
'jdbc:oracle:thin:#(DESCRIPTION=(ENABLE=BROKEN)(FAILOVER=on)(CONNECT_TIMEOUT=5sec)' +
'(TRANSPORT_CONNECT_TIMEOUT=3sec)(RETRY_COUNT=3)(LOAD_BALANCE=on)(ADDRESS_LIST=(LOAD_BALANCE=on)' +
'(ADDRESS=(PROTOCOL=TCP)(HOST=HostName)(PORT=port)))(ADDRESS_LIST=(LOAD_BALANCE=on)' +
'(ADDRESS=(PROTOCOL=TCP)(HOST=HostName2)(PORT=port)))(CONNECT_DATA=(SERVICE_NAME=ServiceName)))'
pds.setURL(dbURL)
More information: Configuring Fast Connection Failover for JDBC Clients
It appears to be working with a connection string containing only host 1.
The Database URL is in the form:
jdbc:oracle:thin:#<hostname>:<port>/<serviceName>
Additionally, I got the error because the .jar file's path was not added to the classpath (click on Test Plan, in the bottom select browse next to Add directory or jar to classpath and select your odbc jar).
Another thing that was wrong was the Validation query, it should be "select 1 from dual" and also the query should not contain any semicolon at the end.
I hope this help people with the same issue.
I am a .Net / SQL Server programmer. I am trying to make an Access database created by someone else to work. It looks like is uses a procedure similar to Save password for ODBC connection to SQL Server from MS Access 2007 but I am using Access 2003 so I suspect something else needs to be done. I don't really know what I am doing with Access but I am stuck with it.
I do have an ODBC connection and it looks like the linked tables use it. The database has an AutoExec which populates some local tables from the linked tables that the reports use. It also calls a qryConnect with a dsn-less connection like the linked article and this seems to work. I have got it to stop asking for a user and password on start up. I can also open most reports without problems, 2 do not work. A form loads on Startup with buttons that basically show reports. This is where it gets odd.
The reports fail from the ODBC driver with the windows credentials. Then a logon box shows up with the correct user (a user with read only privileges) but the trusted connection box is checked. I do not have the trusted box checked in the DSN. Not do I have Trusted_Connection=Yes in the DSN-less connection in qryConnect.
This is the code in the form
stDocName = "rptNegativeLotQtys"
DoCmd.OpenReport stDocName, acPreview
I don't know how I buggered it up so much and before I try again copying everything to a new mdb and trying again I am hoping to get some guidance.
On a side note I can open everything fine on my machine. I am an administrator as far as Windows is concerned but not SQL Server.
EDIT:
I created a new DSN just for these reports. Then I deleted all linked tables and re-linked then using the new DSN. I looked at the linked tables in MsysObjects and the new DSN is listed there. Yet Access still prompts for the password. It appears that it is not caching the password.
Actually, you do NOT need to add nor store the UID/Pass in the connection strings used. However, what you MUST ensure is that all connection strings are the SAME. If they are different, then the cached UID/password will not work.
Also, make sure you do NOT connect nor open a table AFTER having connected using Windows Auth – the reason being then when you add the table links (especially via code), then the cached setup of using windows auth will occur, and thus prompts will occur when the links suggest to do otherwise. In other words linking and attempted to use SQL logons will NOT work if you already opened any table link via windows auth (so exit the database and do NOT open any table that could/can use windows auth).
So I would delete the links, and re-create them – but again, ensure that you never connected as a windows auth user to SQL server.
So the "cache" that access has is a GREAT friend/feature to eliminate the need to include UID/pass in the connection string - but the SAME feature will bite you VERY bad if you at any time connecte to the database in question via windows auth.
How to “cache” the user logon and ID is explained here:
Power Tip: Improve the security of database connections
http://blogs.office.com/b/microsoft-access/archive/2011/04/08/power-tip-improve-the-security-of-database-connections.aspx
So you “can” include the UID/LOGON in the linked tables, but above shows that a ONE time logon can also be used. So be VERY careful when setting up table links – due to the above “cache” of the user and HOW they logged into the database – code that ATTEMPTS to create table links based SQL logons will actually wind up using windows auth if you already connected as such (so exit the database if you going to re-link using SQL logons).
Keep in mind, Access does NOT use the DSN AFTER you linked the table. The information from the DSN is a ONE TIME copy to the connection string. You can verify this by going into my documents and deleting the DSN you used. Assuming the linked table was working correctly, you find that they CONTINUE to work EVEN if you delete the DSN. In effect this means that linked tables are DSN less except for when you create the linked table. This allows you to easy copy the application to different computers without having to copy the DSN.
As to ensure that all the linked tables use the same connection string, it is a simple matter to delete them all, and re-link.
You can also hit ctrl-g to bring up the debug window, and look at the connection string this way:
? currentdb.TableDefs("linked table name").Connect
the result in the debug window for a windows auth connection string will look like this:
ODBC;Description=test DSN;DRIVER=SQL Server;
SERVER=albertkallal-pc\SQLEXPRESS;
Trusted_Connection=Yes;
APP=Microsoft Office 2010;DATABASE=AxisMIS
Note how in above we see "trusted connection" (that means windows auth).
If I linked the table using SQL logon (and REMEMBER to check save password), then you see this:
ODBC;Description=TEST3;DRIVER=SQL Server;
SERVER=ALBERTKALLAL-PC\SQLEXPRESS;
UID=MySQLogon;PWD=MyPassword;
APP=Microsoft Office 2010;DATABASE=AxisMIS
Just remember during the table link process to "check" the save password.
eg this:
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.
Every SQL Server connection string I ever see looks something like this:
Data Source=MyLocalSqlServerInstance;Initial Catalog=My Nifty Database;
Integrated Security=SSPI;
Do I need the Initial Catalog setting? (Apparently not, since the app I'm working on appears to work without it.)
Well, then, what's it for?
If the user name that is in the connection string has access to more then one database you have to specify the database you want the connection string to connect to. If your user has only one database available then you are correct that it doesn't matter. But it is good practice to put this in your connection string.
This is the initial database of the data source when you connect.
Edited for clarity:
If you have multiple databases in your SQL Server instance and you don't want to use the default database, you need some way to specify which one you are going to use.
Setting an Initial Catalog allows you to set the database that queries run on that connection will use by default. If you do not set this for a connection to a server in which multiple databases are present, in many cases you will be required to have a USE statement in every query in order to explicitly declare which database you are trying to run the query on. The Initial Catalog setting is a good way of explicitly declaring a default database.