I am attempting to set up a MS Flow to add data to my SQL Server database. To set up the Flow Connection there are only six items:
Connect via on-premise data gateway
Connection Name
SQL server Name
SQL database Name
Username
Password
However, when I fill in the appropriate information I get the following error "Please check your account info and/or permissions and try again."
Please note that I can login to my database via SMSS and run queries (e.g. create a table)
Some complexities that are likely affecting the outcome:
(A) I have to logon to a VPN to my University (with my University ID/Password) before I login to the database via SMSS (with my database Login/Password using SQL Server Authentication).
I have tried to create the connection using all sorts of permutations (e.g. on the VPN vs. off the VPN, University ID vs database ID) but have been unable to find the right combination.
(B) I not on campus (and rarely am).
(C) I did not realize until now that there is a paid Flow and my University has the Free plan. However, looking at the features/pricing I should be able to hook up to my SQL Server database.
The error I am getting is both specific but not very helpful as far as giving me any hints on what to change.
With only six options, there is not a lot I can do with the MS Flow. Is there a setting within the SQL database that I need to change?
Related
I'm trying to to the GoldenGate on Microsoft SQL Server. The thing is stopping me from moving forward with the implementation, there is a error I always get when trying to create the cdc Cleanup setup job file from the GGSCI. Only, please feel free to participate. the error bellow, keep in mind I have done all the requirements that appears in the error.
( Command: createJob
Neither the SQL Server Change Data Capture job nor Replication Log Reader Agent are found in database test1.
Ensure that supplemental logging is enabled for database 'test1' and that either the SQL Server Change Data Capture job or the Replication Log Reader Agent exists, if the database is Published for Transactional Replication, and re-run this program.
Also, ensure that the SQL Server login is a member of the sysadmin server role.)
I was expecting the createJob file to be created on the SSMS.
I have a SQL statement that merges 2 databases together, from 2 different servers (SQL Server 2012 for both).
The two servers are linked, so when executing the statement in a query window from Management Studio with the SA account it works perfectly.
However, I need to automatize this. I created a Job in the SQL Server Agent, and I keep getting an authentication error. This is because the user that is executing the SQL Server Agent service doesn't have the SA rights on both servers.
This is the error:
The OLE DB provider 'providerName' for the connection server
'serverName' reported an error. Authentication failed.
I tried setting a superadmin user from the Active Directory with all rights on both servers to execute the SQL Server Agent, but I still get the error.
Is there any way to fix this?
Thanks
You can store your linked server credentials with your linked server definition (forbid my picture editing skills ;-)):
Alternatively - and much more preferabele from security point of view - setup same account on both servers (you can then limit the account privileges as you need) and use the third option ('Be made using the login's current security context')
I'm having issues connecting to a SQL Server 2014 database using Management Studio with SQL Authentication. This server was just created by my IT department. I restored a database, I added the login with a password, I made sure the server properties had both SQL Authentication and Windows Authentication checked. I made sure the user at the database level is mapped to the login. But when I try to connect using Management Studio I get the following error. However, it works if I use my Windows Authentication account.
Actually, I kept getting the normal 'Login Failed' message. But this morning I got the above error which is probably more helpful. When I kept trying again, I kept getting the normal Login Failed message.
Have you seen this Microsoft TechNet post about the message you received? It looks like your admin may need to adjust the SQL Server configuration.
Specifically, it looks like you might need to try one of:
Connect using TCP/IP, or use the SQL Server Configuration Manager to
enable remote connections using named pipes.
or...
Using SQL Server Configuration Manager on the client computer, move
TCP before named pipes in the protocol order list.
I've been trying to connect to SQL Server using SQL Server Management Studio to no avail.
This is what the error says:
Cannot connect to .\HAMED.
ADDITIONAL INFORMATION:
Login failed for user 'HAMED'. (Microsoft SQL Server, Error: 18456)
I have an instance of SQL Server by the name of Hamed which is run in Network Sevice mode. I'm using Windows 7.
I'm guessing you didn't grant yourself SQL admin during the install, but are you sure the DB instance is "HAMED"? That sounds like the machine name. Try connecting to .\sqlexpress
Do you remember the SA password? If so, you can add yourself by logging in with that account. Otherwise, you'll have to jump through some hoops and loops to get yourself added.
If you forgot to add yourself to the SQL admin group, read this article:
http://blogs.ameriteach.com/chris-randall/2009/12/11/sql-server-2008-forgot-to-add-an-administrator-account.html
It looks like you're trying to use "SQL Server Authentication" in the login dialog in SSMS, but the user that you're trying to use is a Windows user/administrator? If so, the fix should be as simple as choosing "Windows Authentication" in the drop-down.
UPDATE: looks like I jumped the gun - this sql server forum thread lists lots of possible issues, including permissions issues, orphan users, etc.
sa... the answer was sa.
I had set the administrative password but didn't know the username to go with it. Very nube, I know, you can hit me with it later.
When I installed SQL it asked me to set administrative password - right now SSMS can login.
Under users I see 1\cory (1 is my machine name - I'm trying a numbering scheme). But if I type that in it fails with the error. SQL says "no, that's an NT login, I can't use those".
Under the users list SQL does in fact show the user as Windows authentication but as I said - for some reason I can't connect using Windows authentication. The connection times out.
I'll just add a direct user name here.
All this is to do the MSVA courses for SQL certification. First exam: get sql SSMS to work.
We recently moved a database from MS SQL Server 2000 to MS SQL Server 2008. Everything works as expected with our main .NET client application but we are having problems with a MS Access 2003 application which connects via ODBC. A System DSN is used to make the connection.
When the database was running on SQL Server 2000 the Access application would request a user name and password once when the program was first started. Now, with the database running on SQL Server 2008 a user name and password dialog is requested every time a different table is accessed I believe.
This behavior occurs when using either the user account we have used for years and it also occurs if I use the database system admin account ( I know this is bad practice, it was just a test. )
What do I need to reconfigure to return to the previous, desirable behavior where the user is only authenticated a single time?
You could look at using a "DSN-Less" connection to MS SQL, microsoft provide instructions here: http://support.microsoft.com/kb/892490
The relevant connection string can be found here: http://www.connectionstrings.com/sql-server-2008#p3
All this aside, JMK's question is important, the method above is for if you are having linked tables to the server present in your Access database, however when working with dedicated database server's I always advise using "ADO" connections rather than "DAO" as this will avail better performance (especially if you are running queries)
If it is just queries you need to run then consider either the ADO method or take a look at the "Pass through" queries option, this like ADO will have the server doing the work rather than the local machine and the performance will be greatly improved.