Connecting to Sql Server Database with hyphenated name - sql-server

I don't seem to be able to find a way to escape this hyphenated database name so that I can open a connection to it. The database name is EDMS-Lok and my code looks like this (ADOcon is an ADO connection object):
strConBase="DRIVER=SQL Server;SERVER=LOKDB;UID=secret;PWD=secret;APP=LokENG_TESTS;WSID=LOKSPEC1;DATABASE=[EDMS-Lok];Network=DBMSSOCN;Trusted_Connection=NO;
ADOcon.ConnectionString = strConBase
ADOcon.Open"
I've tried the database name without enclosing brackets. I've tried enclosing it in square brackets, curly brackets, parentheses, back-ticks, single quotes, double quotes, etc. I've tried backslash and exclamation points. I can't find a way to escape the database name so that I can connect to it.
The error message I get is:
Run-time error '-2147467259 (80004005)':
[Microsoft][ODBS SQL Server Driver][SQL Server]Cannot open database "[EDMS-Lok]" requested by the login. The login failed.
The database name and credentials are correct. I can access it if I omit the database name argument from the connection string, and then use the fully qualified name in my SQL statements (i.e. SELECT * FROM [EDMS-Lok].dbo.tablename)
However, I really don't want to do this, as I'm trying to use modular code that does the same actions on multiple databases. What I want is to open the connection to one database, run some SQL procedures, close the connection, then open a connection to another database and run the same SQL procedures. Lather, rinse, repeat.
Also, before someone asks, I do not have the option of changing the database name.
As a test, I used the exact same connection string to connect to another database on the server that did not have a hyphenated name and it worked without error, so I'm pretty sure it's the stupid hyphenated name that is the problem.

I could not get this to work the way I wanted to through an ODBC connection using the MSDASQL provider.
I ran some tests and I seem to be able to connect through OLE DB using the SQLOLEDB provider. So, I think I will just go back and modify the existing code to use an OLE DB connection.
Using OLE DB, I've found I can leave the database name un-escaped, i.e. INITIAL CATALOG=EDMS-Lok; or I can escape using double quotes, i.e. INITIAL CATALOG="EDMS-Lok";. Square brackets however threw an error when I tried them, so for now I will stick to double quotes or un-escaped database names.
Thanks!

Related

SSIS SMO Connection to SQL Server, using the Transfer Objects Task, throws various connection type errors

We are running an SSIS Package from a SQL Server 2014 instance which connects to a remote SQL 2016 Server through an SMO connection in a Transfer Objects Task. This task retrieves schemas, tables and SP's. The SSIS package has three of these tasks running in parallel which connect to three different Db's on the same SQL server.
Things had been running fine until a day last week the owners of the remote SQL Server decided to create a new user/password combo to give to us. No permissions changed or anything else, only the u/p.
After they did that the package has been failing with various connection type errors. The errors happen randomly on the three parallel tracks. Here are the errors:
Failed to retrieve data for this request.
Invalid Operation: The connection is closed.
There is already an open DataReader associated with this Command which must be closed first.
Property TextHeader is not available for StoredProcedure '[Sp Name]'. This property may not exist for this object, or may not be retrievable due to insufficient access rights. The text is encrypted.
But on the DB side the error the profiler was showing was the password was invalid. This is not true.
After some extensive troubleshooting we tried giving he user SA rights, which did not help. On further work we tried changing the password to 123 (while keeping SA rights,) the prior password had been a 10+ char non-alpha-numeric (had the ! char) password, for example aBc12dEF3!!!. We tried removing the ! chars and various other iterations, but that didn't work then we finally got it down to the password being 123.
This final password change worked. But obviously this is not normal, we cannot have user with SA rights and 123 as password.
Does anyone have any ideas, advice, direction on what could be going on here?
Thanks!

Having trouble connecting to SQL Server database from VBA using ADO connection

I want to connect to a SQL Server database without using DSN. I'm receiving an error when trying to connect to said database. The error is
Run-time error '-2147467259 (80004005)': [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
My connection string looks like this:
"ODBC;DRIVER=SQL Server;SERVER=lokdb; UID=secret;PWD=secret;APP=Microsoft Open Database Connectivity;WSID=" & Environ$("COMPUTERNAME") & ";Network=DBMSSOCN;Trusted_Connection=Yes;DATABASE=EDMS-Lok"`
I am able to connect to the default database on the server with the credentials specified if I remove the DATABASE=EDMS-Lok parameter from the connection string, however I don't then seem to be able to "find" the EDMS-Lok database. E.g. if I try using
SELECT * FROM EDMS-Lok.dbo.eng_dwg
I get an error message
Run-Time error '-2147217900 (80040e14)': [Microsoft][ODBC SQL Server Driver][SQL Server]Incorrect syntax near '-'
(eng_dwg is a valid table)
When I connect without specifying a database, the .DefaultDatabase property of the ADO connection object returns "020" which I don't even see as an available database on that server??
When connected, if I use SELECT name FROM sys.databases I'm able to get a list of the databases available. They are:
010
100
500
EDMS-Lok
Master
msdb
MSLLockDB
pubs
tempdb
I got it working using DSN, but I don't want to use DSN.
Not sure what is wrong here??
I would say the problem is that you mix up the authentication models. You provide user + password but also you have configured trusted connection = yes. I'm not sure how ADO works in that case but I would assume that it doesn't use the configured user and connects with the windows account. Delete the trusted connection parameter in the connection string and try again.
OK, credit for this answer should go to Dee and Sam who commented on the original question, however I can't mark a comment as the answer, so here it is:
Needed to wrap the database name in square brackets [ ] ... like this DATABASE=[EDMS-Lok] - (credit to DEE)
I first tried wrapping the database name in the connection string i.e. DATABASE=[EDMS-Lok] and this did not work (same error). However, if I connect without specifying the database, I'm able to access the table using SELECT * FROM [EDMS-Lok].dbo.eng_dwg
It didn't work in the connection string because the string is not T-SQL code. To get it to work, you may need to figure out how to escape the dash character. – (credit to SAM)
I've tried single and double quotes, backslash, square brackets, parentheses and curly brackets and nothing seems to work to escape the hyphen in the database name within the connection string. But, since I can now access the database and the tables I need, which was the original question, I wanted to mark it as answered.

Query database with period in name on a linked SQL Server

I need to query a database on a linked server, and unfortunately the database name contains a period.
This fails;
select top 10 *
FROM [LINKED_SERVER].[DATABASE_NAME.1].dbo.[TABLE_NAME]
with this error:
OLE DB error trace [Non-interface error: OLE DB provider unable to process object, since the object has no columnsProviderName='SQLOLEDB', Query="DATABASE_NAME.1"."dbo"."TABLE_NAME"'].
Msg 7357, Level 16, State 2, Line 2
Could not process object '"DATABASE_NAME.1"."dbo"."TABLE_NAME"'. The OLE DB provider 'SQLOLEDB' indicates that the object has no columns.
Connecting to the same linked server without a period in the database name works;
select top 10 *
FROM [LINKED_SERVER].[DATABASE_NAME].dbo.[TABLE_NAME]
As there are many references to the existing database name out of my control, I hope to find a solution that avoids re-naming the database permanently.
I would like to be able to create a synonym or some other alias, or find some other way to get this working.
Periods in database names accessed via linked servers are perfectly acceptable when escaped with brackets [] - the error your getting must be something else.
I can confirm this on my test rig:
One thought, your using the old SQLOLEDB provider for your linked server, have you tried using SQLNCLI10 instead?
Avoid periods in identifiers,
e.g. in SSMS
sp_help [sales.order]
will not work, even with brackets

finding the correct connection string for a local SQL instance

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

What is the point of "Initial Catalog" in a SQL Server connection string?

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.

Resources