This was the second time this issue was happening. after a server restart, I couldn't connect to the SSAS tabular model through SSMS with neither my own username (admin) nor the service account.
However, we could all connect to the model from other servers in the network.
The icon changes to this as well :
after restarting the service a few times and restarting the server and running CHKDSK \R on all drives and getting to nowhere, it gets fixed by itself.
We are really concerned as we cannot find the root cause of the issue and don't want this to happen when we go live with the project. any idea?
Please ensure when you are trying to connect to SSAS or SQL locally that you open SSMS with Run as Administrator. My assumption is that your account has been given access through the local Windows Administrators group (rather than through direct permissions on your username or through different group permissions). When that is the case, Run as Administrator is required to utilize those local Administrators group permissions on the local server. This is not the case when connecting remotely to a server.
Related
I've setup a Service Broker on one of databases to automatically pick up stored procedures in a specific schema (Build) and run them on a daily basis. So far everything has been running fine, however we've now got a need where we need to access a remote sql server which is running SQL Server 2017 and has the latest Machine Learning Service installed.
I've given the service account that runs the primary SQL Server (SQL 2016) access on the remote server, and ensured the Service Broker is executing under the service account, rather than the local SQL account (sa).
Whenever we try to access the remote server, we are getting the following error:
Linked servers cannot be used under impersonation without a mapping
for the impersonated login.
I've tried adding an EXECUTE AS to the process, however this doesn't seem to make a difference. I've also ensured it is running under the service account, and it is.
I can get it to work using a mapped login on the linked server, however this isn't ideal, as we don't want to run the sql server in mixed authentication as this has been determined as an IT risk.
I've run out of ideas or what I can do here, and can't find any other help pieces with this same problem. I did want to roll this process out to more of our warehouse builds, however this is a deal breaker at this stage.
help?
I was happily using mysql command line in my mac to connect Azure Database for MySql. But all of sudden it started throwing an error saying:
ERROR 2003 (HY000): Can't connect to MySQL server on 'XXXXXXXX.mysql.database.azure.com' (61)
I can see the the database instances is running alright, as I'm able to use the database from an application that is running in Azure.
Has anyone else experienced this?
This problem occurred because the particular network i was connected to not allowing any such connections. Later when i tried from my usual network ( home / office )it got connected. I haven't made any changes in my Azure Db for MySql nor in my local machine, this proves that problem was with that particular network.
It sounds like firewall rules were not setup for that specific network. Can you confirm by looking at this doc?
https://learn.microsoft.com/en-us/azure/mysql/concepts-firewall-rules
Basically, you can click "Add my IP" which would add your current network's Client IP. However, if the network you are on SNAT's out with multiple IP's, you would need to add the entire range from your networking team.
Thanks.
James
I have been trying to run debugging within SQl server management studio and for some reason the debugger has just stopped working.
This is the message I get:
Unable to start the Transact-SQL debugger, could not connect to the
database engine instance 'server-sql'. Make sure you have enabled the
debugging firewall exceptions and are using a login that is a member
of the sysadmin fixed server role. The RPC server is unavailable.
Before this I get two messages, one requesting firewall permissions and the next says 'usage' with some text that makes little sense.
I have looked at the other similar answers on there for the same message which suggest adding the login as a sysadmin but that is already set. I also tried adding sysadmin to another account but that also didn't work.
In the end I was able to start it by right clicking and selecting run as administrator.
I encountered this issue while connected to SQL using a SQL Server Authenticated user. Once I tried using a Windows Authenticated user I was able to debug without issue. That user must also be assigned the sysadmin role.
This happened to me and I could not find the resolution anywhere. My firewall is disabled so I knew that couldn't be the issue.
According to Microsoft: Configure firewall rules before running the TSQL Debugger:
The server needs to communicate back to the client via RPC. The
account under which SQL Server service is running should have
authenticate permissions to the client.
We had a group policy that was preventing this:
Deny access to this computer from the network (Local account, Guests)
In order to resolve the issue, I had to add the SQL Server service account to the local group "Remote Desktop Users" on my desktop. Hope this helps someone else resolve this frustrating issue.
I try with the following steps, but it did not work (maybe because I'm on a PC in a office and I don't have control of the firewall). But you can try the following.
Check the users role:
IF IS_SRVROLEMEMBER ('sysadmin') = 1
print 'Current user''s login is a member of the sysadmin role'
Follow these instructions:
configure the transact-SQL Debugger
Run SQL Server Management Standard Edition 64 bits (with SQL Server Account)
In my case, I received this error message:
Unable to start the Transact-SQL debugger, could not connect to the computer "local".
I end up close the existing connection, then reconnect to my local SQL server using IP 127.0.0.1 and it works.
What helped me, was from here:
SQL Server Management Studio must be running under a Windows account that is a member of the sysadmin fixed server roll.
The Database Engine Query Editor window must be connected by using
either a Windows Authentication or SQL Server Authentication login
that is a member of the sysadmin fixed server role.
So, I've added sysadmin role to my windows account and run ssms as administrator. Debugger started working normally.
In addition to above works, what make our 2 computers remote debug able, was running: (right click on Window's Start button)
System--> Advanced System Properties-->Computer Name-->Click on Network ID... button
and running that wizard to join workgroup on both computers.
I found this solution by looking at my Windows' Event Viewer and looking for a solution to errors with NetBT Source, that is related to workgroup and computer Name.
Update: after some days, it stop working again.
I had the same problem and double checked al recommended settings. At some point I disabled the firewall on the database server and it worked like a charm. By enabling and checking the Firewall log I noticed this entry:
2019-10-31 16:07:50 DROP TCP 192.168.xxx.xxx 192.168.xxx.xxx 65231 61214 52 S 56576751 0 8192 - - - RECEIVE
When I allowed TCP port 61214 (Inbound rule) and switched the firewall back on, it worked. I don't know why this port is needed, maybe some here on SO?
Anyway, maybe the firewall log can be of help too.
Struggled through many hours and got the answer
You can do the configuration through this doc
https://learn.microsoft.com/en-us/sql/ssms/scripting/configure-firewall-rules-before-running-the-tsql-debugger?view=sql-server-ver15
(1) 2 settings need to done on the remote server where Sql server is installed
(2) 1 setting at client computer (i.e) our computer
I brought my laptop home from work hoping I could get some tasks done over the weekend. Unfortunately, I couldn't login to SQL Server using Windows Authentication. I've checked the SQL Server Configuration Manager and the instance (MSSQLSERVER) is set to Log On As Local System, which supposedly means that I should be able to login fine using Windows Authentication... or am I missing something here? Note that in the login window, I tried a lot of different combinations and it always keeps telling me that connection failed because the server is not accessible or I'm not authorized to access it.
A little background about how the instance was installed: I installed and configured it myself. I chose the Mixed Authentication mode and gave a password to the default sa user (which isn't working either by the way). The thing I suspect could be the problem is the fact that I installed the SQL SERVER instance when I was logged in as my Domain User at work (DOMAIN\UserName). Now I'm at home and I do not have access to the LAN at the office, so I'm logged in as the {COMPUTERNAME}\Kassem user.
Any thoughts?
A windows account has to be added to SQL Server to have any rights. If you didn't add {COMPUTERNAME}\Kassem, you can't login to SQL Server.
The recovery option here is the SA password, which should always work.
To connect to the default instance, connect to localhost or .. Connecting to .\MSSQLSERVER won't work, even though MSSQLSERVER is the default instance name.
I am trying to backup my sql server 2005 database using the query
backup database marksheet to disk='e:\backup\marksheet.bak'
when i execute the query it shows the following error
cannot open backup device 'e:\backup\marksheet.bak' operating system
error 5(access is denied)
I am using windows xp
please help me..
The account running the SQL Server service does not have access to that folder.
It doesn't matter if you have access to that folder.
You need to check the security permissions on the folder you are trying to backup to. Make sure the service account (Network Service) has write permissions. It may well not do.
SQL on changing the service account changes the permissions on the critical drives it knows about but won't do it for all the drives in a server.
Try adding the domain account that runs all SQL Services to the security of "e:\backup\".