I have a cube running on SSAS SQL Server 2012.
Every time I want to connect to a cube, or update data in files that contain it, I (and all the other users) get the "Transport Layer Error" message.
I click "OK" and am prompted to re enter my credentials. Usually it works after that (though sometimes it doesn't).
This becomes very annoying when I need to refresh a file that contains a dozen of cubes: I need to enter the credentials 12 times.
Sometimes it becomes impossible to connect to the cube, I get stuck in a Transport Layer Error infinite loop.
Important note: The server is on a different domain than the PC, I am connected to it through a VPN.
Is there any way to get rid of this?
You should do it like this to avoid problems again
Data tab... From Other Sources... From Analysis Services...
Type in a server name, username, and password... click next
choose your database and click next
Check "Always attempt to use this file to refresh data". And check "Save password in file". Click Yes when the prompt pops up.
Click finish.
That will save your username and password (in clear text) into the odc file. (Be aware of this for security purposes.)
And if that doesnt help, try to create a whole new excel workbook and readd connections to the cube.
Related
My company is using Tableau for Served data, but I have user who want Excel text table type data served - Text Tables with many columns, >100k Rows, color conditional formatting - which Tableau deals horribly with.
Everyone also has Excel, so I thought that I could set up an Excel file to pull the data from the SQL Server and be refreshed on demand by the users. I had found an article here about using Microsoft Query within Excel to access the data source.
In Sql Server, I have a scheduled stored procedure that performs a nightly refresh of a results Table I have created I'll call that Table "[Server].[dbo].[Results]". This is the Table that I was trying to display in Tableau - and everyone would have been able to access it, but it runs so slow, it is worthless.
I created the same thing in Excel, and it loads or refreshes data from [Server].[dbo].[Results] in < 30 secs with ~30 columns and > 100k rows with lots of colored conditional formatting. It works great.
So, for Excel, I had our IT department create a user account that only has read-only access to the [Results] Table - that account does NOT have access to anything else in the Server Databases. The credentials are something like Username = "ResultsUser" and Password = "ResultsPassword". Again - EVERYONE would have had read-only access to this data if I could have gotten Tableau to work, so we don't care who knows this UserName and Password. In my Excel file, I used these credentials when I created the Data Connection to [Server].[dbo].[Results], and I DID select "Save Password" for the Connection String
It refreshes fine for me on my work computer over our VPN, but when I sent the file to my user, she cannot refresh the data on her work computer over the VPN. If I dig into the Connection Properties, even though I can see embedded "ResultsUser" and "ResultsPassword" in the Connection String, I also can see MY Windows UserID listed for the WSID. Not sure if this is what is preventing my user from being able to refresh.
Some places I read, it sounds like the embedded credentials, just make it so the creator of the file (me) doesn't have to enter username and password when they refresh the data. What I need is - with ResultsUser and ResultsPassword credentials embedded in the file - ANY USER of the Excel file can refresh the data - as long as they are on the network.
Does anyone know if this is possible? Is there something I am missing? Do I need to use some other technique?
Thanks in advance,
MikeC
we've recently set up alerts for failed connections to database using Azure Monitor. We started getting a bunch of failed connection alerts from all of our databases.
After some investigation in system log using etc query
SELECT *
FROM sys.event_log
WHERE event_type = 'connection_failed'
ORDER BY start_time DESC
I can see that there are lost of 'Login failed for user.' and 'Login failed for user '%.*ls'.%.*ls%.*ls' messages.
Now I was able to find that this seems to be specifically Error 18456 with State 122 https://learn.microsoft.com/en-us/sql/relational-databases/errors-events/mssqlserver-18456-database-engine-error?view=sql-server-ver15 which according to documentation is 'Failure due to empty user name or password.'
All of our applications seem to work in a correct way but the error occurs on all 4 databases including 'master' almost all the time. I'm not sure how to debug exactly what's causing this. I've looked at some potential reasons but nothing seems to be the case.
Edit:
I just talked with some developers. They mentioned that sometimes when they login to SQL Azure Db from their local PC's using SQl management studio they have network issues after some time and they are logged out. I'm just not sure whether this is the real reason for these since logs don't tell that much.
Regards.
Please enable Auditing on your Azure SQL Database to further investigate. After that you can click "View Audit logs" and search for Event type "Login" and action not successful.
Once you filter login events, make a click on any event, scroll the window that shows the detail of the event you just clicked on, and you will see important information like IP address of the host.
If you use the dashboard available on the "View Audit Logs" you can have details by type, by IP address and by principal. Just click on the type you would like to see details, and you will get all related events, each one will all details.
Make a click on the IP addresses that you don't recognize (left side on below image), make a click on the failed login attempts for each principal (right side on below image, where you see the Pie chart).
I have no issues with windows authentication. However, using sql server authentication and selecting to save my password on the connection properties seems to work fine to pull up the databases and tables of a particular sql server instance, but when I try to drag and drop table objects into the object relational designer I get the following error...
"Failed to retrieve data for this request. Failed to connect to server (local). Login failed for user 'myusername'".
I've tried changing some advanced settings such as "authentication = sql password" to no avail. As far as I can tell, it is not storing my password in the connection string and I cannot find any way to manually change this. It forces me to use the dialog box to make changes to the connection string. My password is entered but is just ********* so ultimately it seems it really is not remembered (even though I've checked that box) and thus why i'm getting the login errors when dragging and dropping tables.
Does anyone know a workaround or fix....or if I'm missing something obvious. In the past (VS2013, VS2015) I don't remember having this issue.
Note that the string looks proper in the app.config file but still does not allow me to drag and drop tables from object explorer.
I have created a project level sql-server connection for my SSIS project. There are multiple packages which utilise this connection and it works perfectly fine. However, I have a new package which contains an "Execute SQL Task". This task also utilises the same connection but throws an error saying "login failed for user".
It might be one of these things:
The Protection level property that is set to DontSaveSensitive, meaning the password doesn't get saved. You can choose to change it to EncryptSensitiveWithUserKey. Although I wouldnt suggest this when you deliver the project to Deployment server
If you are using package configuration and saving the connection string to a XML File (for example) the password won't get saved, you have to add it manually. Something like: ;Password=someReallyCoolPassword;
Even if you do at the password manually, it can still have some problems. I believe it can be that the word "Password" is sensitive itself, and even if you have protection level as DontSaveSensitive, when the package read the XML File, it wont read the password value. I have no idea why, but have to put a blank space before Password, like this: ; Password=someReallyCoolPassword; and it will work, although your connection could be seen if someone hover the mouse over the connection manager.
If you could add more information about how you are handling your connection, I could give you a mroe specific answer
I am a .Net / SQL Server programmer. I am trying to make an Access database created by someone else to work. It looks like is uses a procedure similar to Save password for ODBC connection to SQL Server from MS Access 2007 but I am using Access 2003 so I suspect something else needs to be done. I don't really know what I am doing with Access but I am stuck with it.
I do have an ODBC connection and it looks like the linked tables use it. The database has an AutoExec which populates some local tables from the linked tables that the reports use. It also calls a qryConnect with a dsn-less connection like the linked article and this seems to work. I have got it to stop asking for a user and password on start up. I can also open most reports without problems, 2 do not work. A form loads on Startup with buttons that basically show reports. This is where it gets odd.
The reports fail from the ODBC driver with the windows credentials. Then a logon box shows up with the correct user (a user with read only privileges) but the trusted connection box is checked. I do not have the trusted box checked in the DSN. Not do I have Trusted_Connection=Yes in the DSN-less connection in qryConnect.
This is the code in the form
stDocName = "rptNegativeLotQtys"
DoCmd.OpenReport stDocName, acPreview
I don't know how I buggered it up so much and before I try again copying everything to a new mdb and trying again I am hoping to get some guidance.
On a side note I can open everything fine on my machine. I am an administrator as far as Windows is concerned but not SQL Server.
EDIT:
I created a new DSN just for these reports. Then I deleted all linked tables and re-linked then using the new DSN. I looked at the linked tables in MsysObjects and the new DSN is listed there. Yet Access still prompts for the password. It appears that it is not caching the password.
Actually, you do NOT need to add nor store the UID/Pass in the connection strings used. However, what you MUST ensure is that all connection strings are the SAME. If they are different, then the cached UID/password will not work.
Also, make sure you do NOT connect nor open a table AFTER having connected using Windows Auth – the reason being then when you add the table links (especially via code), then the cached setup of using windows auth will occur, and thus prompts will occur when the links suggest to do otherwise. In other words linking and attempted to use SQL logons will NOT work if you already opened any table link via windows auth (so exit the database and do NOT open any table that could/can use windows auth).
So I would delete the links, and re-create them – but again, ensure that you never connected as a windows auth user to SQL server.
So the "cache" that access has is a GREAT friend/feature to eliminate the need to include UID/pass in the connection string - but the SAME feature will bite you VERY bad if you at any time connecte to the database in question via windows auth.
How to “cache” the user logon and ID is explained here:
Power Tip: Improve the security of database connections
http://blogs.office.com/b/microsoft-access/archive/2011/04/08/power-tip-improve-the-security-of-database-connections.aspx
So you “can” include the UID/LOGON in the linked tables, but above shows that a ONE time logon can also be used. So be VERY careful when setting up table links – due to the above “cache” of the user and HOW they logged into the database – code that ATTEMPTS to create table links based SQL logons will actually wind up using windows auth if you already connected as such (so exit the database if you going to re-link using SQL logons).
Keep in mind, Access does NOT use the DSN AFTER you linked the table. The information from the DSN is a ONE TIME copy to the connection string. You can verify this by going into my documents and deleting the DSN you used. Assuming the linked table was working correctly, you find that they CONTINUE to work EVEN if you delete the DSN. In effect this means that linked tables are DSN less except for when you create the linked table. This allows you to easy copy the application to different computers without having to copy the DSN.
As to ensure that all the linked tables use the same connection string, it is a simple matter to delete them all, and re-link.
You can also hit ctrl-g to bring up the debug window, and look at the connection string this way:
? currentdb.TableDefs("linked table name").Connect
the result in the debug window for a windows auth connection string will look like this:
ODBC;Description=test DSN;DRIVER=SQL Server;
SERVER=albertkallal-pc\SQLEXPRESS;
Trusted_Connection=Yes;
APP=Microsoft Office 2010;DATABASE=AxisMIS
Note how in above we see "trusted connection" (that means windows auth).
If I linked the table using SQL logon (and REMEMBER to check save password), then you see this:
ODBC;Description=TEST3;DRIVER=SQL Server;
SERVER=ALBERTKALLAL-PC\SQLEXPRESS;
UID=MySQLogon;PWD=MyPassword;
APP=Microsoft Office 2010;DATABASE=AxisMIS
Just remember during the table link process to "check" the save password.
eg this: