So I am new to the Azure Data Studio and I am trying to make a new connection. I tried the method below:
The method I tried
My password adheres to the rules: "at least 8 characters long and contain characters from three of the following four sets: Uppercase letters, Lowercase letters, Base 10 digits, and Symbols" and I followed the code strictly. However, when I input the values, the Azure is giving me " error: 40 - Could not open a connection to SQL Server: Could not open a connection to SQL Server)." What are some simple steps I can perform to check what went wrong? How do I allow the remote access?
Related
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!
At first, please note that I am aware that this question has already been asked several times. However, the accepted (and non-accepted) solutions given so far did not work in my case, so something substantial must have changed since then, which hopefully justifies asking again.
Having said this:
I am currently trying to upgrade an Access 2010 .adp application to Access 2019 .accdb. The application includes a lot of VBA code which uses ADO objects to connect with and operate on Microsoft SQL server (currently: 2008 R2, but will be upgraded soon).
I'd like to keep the most part of the code, which means to stick with ADO, so the way to go is the new OleDB SQL server driver (which has been undeprecated / newly released in 2018). The SQL server runs on another machine than my client application.
I am not able to establish a connection to SQL server from VBA. When executing the following code snippet
Dim cnTemp As Connection
Set cnTemp = New Connection
cnTemp.CursorLocation = adUseServer
cntemp.Open "Provider=MSOLEDBSQL;Server=dbserver.example.com;Initial Catalog=MyDB;Authentication=SqlPassword;User ID=sa;Password=secret;DataTypeCompatibility=80;"
I get the following error when the last line is executed:
SSL Provider: The certificate chain was issued by an authority which is not trusted.
OK, no problem, after all we have found all the other questions dealing with the same issue, all suggesting the same solution: Add Trust Server Certificate=True; to the connection string.
Well, tried that, but -to my surprise- still the same situation. Then I tried some other variants like TrustServerCertificate=True; or using true instead of True, but to no avail. I also tried adding Use Encryption for Data=True; which didn't help either (that could be expected). Furthermore, I tried some of the snippets I had found when researching the problem, but which are not documented by Microsoft as being valid in ADO connection strings (like Encrypt=true or Trusted_Connection=true;); of course, that made the situation worse, raising other error messages.
I have understood that I could solve that problem by putting the SQL server certificate into the client's trusted root certificate store, or by having SQL server use a certificate which has been issued by a known, trusted CA (e.g. Let's Encrypt).
However, I'd strongly like to know why adding Trust Server Certificate=true; to my connection string does not make the error go away and what I have to put in there to disable certificate validation (and by the way, I would be grateful if we wouldn't start a discussion about why this would be bad; this is just development and testing in a trusted, closed network, and I am aware of possible risks).
The reason TrustServerCertificate=True in the connection string is not honored is twofold. One is that it isn't a valid ADO classic (ADODB) connection string keyword. According to the ActiveX Data Objects (ADO) Connection String Keywords documentation, the keyword/value pair should be Trust Server Certificate=True (note spaces). The keyword is ignored entirely without the spaces and not trusted as a result.
However, this change alone will not trust the certificate because of the Authentication-SqlPassword specification. When the Authentication keyword is specified, the documentation footnote calls out:
To improve security, encryption and certificate validation behavior is
modified when using Authentication/Access Token initialization
properties or their corresponding connection string keywords. For details, see Encryption and certificate validation link.
The referenced link includes this important note:
Certificate validation can also be controlled through the Value field
of the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\SNI18.0\GeneralFlags\Flag2
registry entry. Valid values are 0 or 1. The OLE DB driver chooses the
most secure option between the registry and the connection
property/keyword settings. That is, the driver will validate the
server certificate as long as at least one of the registry/connection
settings enables server certificate validation.
So even with Trust Server Certificate=True, the cert will be validated when this registry value is set to 0.
One solution is to simply remove the Authentication=SqlPassword specification as long as you don't need the improved security provided by not trusting the server certificate:
cntemp.Open "Provider=MSOLEDBSQL;Server=dbserver.example.com;Initial Catalog=MyDB;User ID=sa;Password=secret;Trust Server Certificate=True;DataTypeCompatibility=80;"
At first, I'd like to state that all credit goes to #Dan Guzman. It's his answer / comment which provided the solution.
However, I'd like to add some background, based on research I've done since posting my question.
The problem is that Microsoft's documentation obviously is wrong. Please have a look at the following document:
https://learn.microsoft.com/en-us/sql/connect/oledb/applications/using-connection-string-keywords-with-oledb-driver-for-sql-server?view=sql-server-2017#table3_1
It is located in the section SQL Server 2017 -> OLE DB -> Applications -> Using connection string keywords with OLE DB Driver for SQL server, so it should be the right one. It is divided into three sections; in the context of this question, the last table is what we're interested in, because only this one relates to connection strings with ADO.
That last table explicitly shows that Authentication=SqlPawword is valid in ADO / OLE DB connection strings (reformatting mine, no content altered):
Authentication SSPROP_AUTH_MODE Specifies the SQL or Active
Directory authentication used. Valid values are:
(not set): Authentication mode determined by other keywords.
ActiveDirectoryPassword: Active Directory authentication using login ID and password.
ActiveDirectoryIntegrated: Integrated authentication to Active Directory using the currently logged-in user's Windows account
credentials.
NOTE: It's recommended that applications using Integrated Security (or Trusted_Connection) authentication keywords or their corresponding
properties set the value of the Authentication keyword (or its
corresponding property) to ActiveDirectoryIntegrated to enable new
encryption and certificate validation behavior.
SqlPassword: Authentication using login ID and password.
NOTE: It's recommended that applications using SQL Server authentication set the value of the Authentication keyword (or its
corresponding property) to SqlPassword to enable new encryption and
certificate validation behavior.
It also says (again, formatting mine, no content altered):
Trust Server Certificate SSPROP_INIT_TRUST_SERVER_CERTIFICATE
Accepts the strings "true" and "false" as values. The default value
is "false", which means that the server certificate will be validated.
Every reasonable human being will understand this in the sense that Trust Server Certificate=true will disable certificate validation.
But when you look here
https://learn.microsoft.com/en-us/sql/relational-databases/native-client/applications/using-connection-string-keywords-with-sql-server-native-client?view=sql-server-2017
you'll notice that this document is structured like the first one, and that the last table does not mention the Authentication parameter.
However, this document is located in SQL Server 2017 -> Development -> SQL Server Native Client -> Applications -> Using Connection String Keywords. That means that it is not relevant for our case because it relates to SQL server native client (and not OLE DB), but it provides the correct information.
So we have the right document which provides the wrong information and an irrelevant document which provides the right information. Congratulations, Microsoft, you have made me waste a whole day again ...
Furthermore, I have found the following document:
https://learn.microsoft.com/en-us/sql/connect/oledb/features/using-azure-active-directory?view=sql-server-2017#encryption-and-certificate-validation
Reading the title ("Using Azure Active Directory"), it should relate to Azure only. However, I suspect that the following section relates to local SQL server installations as well (formatting mine, no content altered):
Certificate validation
To improve security, the new connection properties/keywords respect
the TrustServerCertificate setting (and its corresponding connection
string keywords/properties) independently of the client encryption
setting. As a result, server certificate is validated by default.
Note
Certificate validation can also be controlled through the Value field
of the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\SNI18.0\GeneralFlags\Flag2
registry entry. Valid values are 0 or 1. The OLE DB driver chooses the
most secure option between the registry and the connection
property/keyword settings. That is, the driver will validate the
server certificate as long as at least one of the registry/connection
settings enables server certificate validation.
So it could well be that we also have to change values in the registry to finally disable certificate validation when connecting to SQL server via ADO / OLE DB.
I am having a weird error.
My task is to import data from Oracle 11g to MS Access (Legacy VBA-Code with a lot of business logic) which is then shipped to MS SQL Server as our new backend via the integrated ODBC-Provider.
The VBA-import works fine until I encounter fields with only space-characters in it which causes the following error in the line rst.Update:
run-time error -2147217887(80040e21), ODBC-call failed
The field (Birthplace) is not mandatory, there are many null-entries or entries with spaces inbetween (New York). The error only occurs when there is nothing in the field except spaces.
The spaces are of the form Chr(32) which is equal to normal space on the keyboard which shouldn't be a problem
When working with an Access frontend/backend, there is no problem with the fields, but when saved to the SQL Server backend, the ODBC Error occurs.
Thanks for your help
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.
Scenario:
Single SQL Server with 2 instances -> .\test & .\live
Single IIS server with 2 websites -> test & live
test website's web.config points to the .\test SQL server instance, live website points to .\live. The SQL Server instances are identical in every way, i.e. DB names, SQL username / password, etc. The only way they differ is by the ports they listen on.
We have the following code deployed to the test website:
_logger.Debug("connection string: " + _context.Database.Connection.ConnectionString);
_context.Database.ExecuteSqlCommand("stored_procedure #param");
When we check the logfile after this code has executed, it shows that the connection string is pointing to the .\test instance, as expected. But a SQL Profiler trace shows that stored_procedure is being executed against the .\live instance.
We can't figure out why or how this is happening, any help?
The missing piece of the puzzle was the ports. As per the comments on this answer, MSSQL ports and instances are the same thing... and port overrides instance name if specified.
Our connection strings looked like the following:
test: Data Source=server\test,7777;Initial Catalog=ourdb;Persist Security Info=True;User ID=user;Password=pass
live: Data Source=server\live,7777;Initial Catalog=ourdb;Persist Security Info=True;User ID=user;Password=pass
So although they were pointing to different instances, the same port overrode that and forced them both to effectively point at whatever was running on port 7777 - i.e. the .\live instance, hence the anomalous behavior we experienced.