Remote Data Access: the user is not associated with a trusted SQL Server connection - sql

I have read all the related posts here and many other discussions on other forums, but still cannot solve my problem.
I am porting a SQL Server CE application from a WindowsCE device to Win 7. The code of interests is to remotely download a table from SQL Server database using SqlCeRemoteDataAccess.Pull.
The original code on WinCE device is as follows:
SqlCeRemoteDataAccess.Pull(Tablename, sql, _remoteConnectionString, RdaTrackoption.TrackingOffWithIndexes, "ErrorTable")
When running on Win7 from Visual Studio 2012, it complains:
Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
I double checked both my local and remote databases. They are not corrupted. Then I searched the Internet and this forum, and tried the suggested solution: changing the connection string from:
Provider=PROVIDER;Data Source=Src;User ID=SUser;Password=1234;Initial Catalog=ABCD_EF;
To:
Provider=PROVIDER;Data Source=Src;User ID=SUser;Password=1234;Initial Catalog=ABCD_EF;Integrated Security=SSPI;
Now I got:
Login failed for user ''. The user is not associated with a trusted SQL Server connection.
I also added Trusted_Connection=Yes or Trusted_Connection=True to the above connection string and saw the identical error. Any suggestions ? Thank you.
NOTE: The server is already set to mixed mode: both Windows and SQL Server authentication.
NEW updating: I am using C# for programming both for the device and on Win7. The remote data server agent is in sqlcesa30.dll (Microsoft SQL Server Compact Edition Server Agent 3.0). The followings are connection strings used and error messages I got:
(1) Original one that Works on WinCE devices, but on Win 7 I got:
Provider=PROVIDER;Data Source=Src;User ID=SUser;Password=1234;Initial Catalog=ABCD_EF;
Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
(2) On Win 7 I got:
Provider=PROVIDER;Data Source=Src;Initial Catalog=ABCD_EF;Integrated Security=SSPI;
Login failed for user ''. The user is not associated with a trusted SQL Server connection.
(3) On Win 7 I got:
Provider=PROVIDER;Data Source=Src;User ID=SUser;Password=1234;Initial Catalog=ABCD_EF;Integrated Security=SSPI;
Login failed for user ''. The user is not associated with a trusted SQL Server connection.

You cannot have both the Integrated Security=SSPI; and User ID=SUser;Password=1234 in a connection string at once. Pick one:
either use the integrated security (recommended) to use your current credentials - but then you must remove the UserID=...;Password=.... parts from the connection string
or then you use a specific user and password - and in this case, adding integrated security or trusted connection is moot since the UserID=...;Password=... settings will be used
So in your case, if you have properly set up integrated security, just use:
Data Source=Src;Initial Catalog=ABCD_EF;Integrated Security=SSPI;
as your connection string.

Related

Unable to connect to a migrated Access database on SQL Server as another user: SQL server Error 4060

I have an Access DB that I migrated to SQL server recently. The SQL server is on a Windows server. Now I can work normally with the SQL database but when others log into the same windows server with their credentials they are not able to access the database. As soon as they open Access frontend they get an error saying failed connection. Now I created an ODBC connection string(File DNS) and gave it to the other users in the network but they still are not able to connect to the database. They get an error stating "SQL server connection failed. The server rejected the connection: Access to the selected database has been denied". Can someone please help me to solve this issue so that multiple users can connect to the SQL DB without any issues? Thanks
Hard to know with the limited information. Are you using windows authentication to sql server, or are you using SQL logons? Either should work fine. The other issue to watch out for is what sql driver did you use to link with?
If you link say using the native 17 ODBC driver, then that is not installed on workstations by default - you have to download and install that driver.
Or, maybe you linked using the long time "legacy" sql driver - that is by default installed on all workstations.
So, it not clear if you using SQL logons, or using Windows authentication for the connection to the database????
If your using windows authentication, then all those other users will require permissions to be granted to the database.
If you using a SQL logon, then that logon would have been saved when you link the table(s), and again it should work for all users. Its quite common to create ONE logon on SQL server, link using that logon, and thus all users will be connecting to the database using the one same logon id/password.
And, if you linked using a FILE dsn, then zero configeration should be required, since access converts FILE dsn's into what are called dsn-less connections. (the origonal file is not required anymore once you link - you can even delete that FILE dsn, and it will still work).
So, FILE dsn is the best choice, since that dsn is NOT required to be setup on each workstation.
And if you using sql logon's, then make sure you checked the box to remember the password during linking of the tables. That is this check box:
And note during a re-link the above box does not appear - only on first time linking of table(s).

Unable to connect to SQL server using vb.net

I am using Connection string in my web.config. I have given user id, password, data source etc in the connection string. When i tried to connect to the SQL server using "Connection.Open()" I am getting an exception stating The user is not authorized. The user name that is mentioned is my windows user name(yes my windows user name and not the one mentioned in connection string). I am not sure why and how this is happening. I tried several times and the same thing is happening.
If you believe that VB.NET is part of the problem, try using the same connection parameters from the same client, but with different client software. For example try connecting from Access or SQL Server Management Studio or Excel. This will help you narrow down whether your problem is with the security configuration versus the code or client software. Often times if you try to connect from a remote workstation you can end up with a failure against a server that has not been configured to allow remote connections.

Error 24 Username and/or password invalid

I have two instances of IBM Informix Database on a HP-UX UNIX box. One instance is for test and the other instance is our live database. The test instance is a copy of the live instance and the usernames and passwords are identical for the two databases. When I connect to the test instance in Visual Studio 2010 using a drda connection string the connection is successful. When I connect to the live instance with the same username and password the connection fails with this error:
ERROR [08001] [IBM] SQL30082N Security processing failed with reason "24" ("USERNAME AND/OR PASSWORD INVALID"). SQLSTATE=08001.
The test connection string is:
Database=companydb;User ID=dbuser;Password=********;Server=dbserver:1403;Persist Security Info=True
The live connection string is:
Database=companydb;User ID=dbuser;Password=********;Server=dbserver:1402;Persist Security Info=True
The only difference between the two connection strings is the port number.
I have searched the IBM website (nightmare) with no luck.
I have installed IBM Data Server Driver Package - IBMDBCL1, IBM Database Add-Ins for Visual Studio and ClientSDK 3.70 (4.1 doesn't support Visual Studio Add-Ins).
The error is misleading little bit: you just unable to connect. As you know Informix doesn't manage users password: the username and password is inherited from operating system user under which Informix is installed. The simplest way is to install both instances under 2 different operating system users and use different ports. When you able to connect with dbaccess to your DB's under 2 this users you will not have this error.

Microsoft OLE DB Provider for SQL Server error '80004005'

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.)

Windows Service not connecting to SQL Anywhere DB

I had built an application to connect to MySQL DB and SyBase - SQL Anywhere DB using VB.NET and appropriate ODBC connections. This was working fine until we had to make this application a service which keeps running in the background irrespective of any users logged in.
I built the application into a service and after installation, the service was able to successfully connect to MySQL DB, but I am getting the following error when connecting to SyBase (please note the connection string is exactly same as used in the application)
ERROR [08001] [Sybase][ODBC Driver][SQL Anywhere]Database server not found
The project installer - service process installer 1 is configured as localsystem.
The creepiest thing here is, mysql connection is successful, when the same application was not a service, connecting to sybase was successful. Once it was made into a service it started failing. I have a Windows 7 64-bit workstation and VS 2010.
I have been trying to do every single thing for the last one week to fix it but nothing seems to be working. Any advice would be highly appreciated.
Looks like you are using a DSN to connect to SQL Anywhere.
First, make sure that you have configured it as a System DSN. Then, verify that you are using a TCP/IP connection protocol (ODBC Admin -> Select System DSN tab -> Select DSN in list -> Click Configure -> Goto Network tab) and NOT Shared Memory.
Using Shared Memory will NOT work from a Win Service that tries to connect to a SQL Anywhere DB Server.
I suspect that is the issue since you are able to connect from a desktop app using the same connection string.
One way to make this work is to start your SQL Anywhere db as a network server (Start -> All Programs -> Sql Anywhere 12 (or 11, depending on your setup) -> SQL Anywhere -> Network Server.
That should run the dbsvr12.exe, which will start listening for connections on a TCP port.
Then, add a Links=tcpip, or a Host=localhost to your Win Service connection string and give that a try!
Take notice that simple win app is running with credentials from logged user, while windows service is running on system account (in your case). You have two options, change connection string to connect with specific user (if you are now using trusted connection) or change windows service logon user to your user.