I am trying to implement ASP.net application which will need to connect Microsoft Analysis Service (SSAS) to retrive data from cube as well as dimensions.
static void Main(string[] args)
{
StringBuilder connectionStringBuilder = new StringBuilder();
connectionStringBuilder.Append("Data Source=MyDataSource;");
connectionStringBuilder.Append("Initial Catalog=MyOlapDatabase;");
connectionStringBuilder.Append(#"User Id=OlapServerMachineName\MyUserName;");
connectionStringBuilder.Append("Password=MyPassword;");
connectionStringBuilder.Append("Provider=MSOLAP.5;");
connectionStringBuilder.Append("Persist Security Info=True;");
connectionStringBuilder.Append("MDX Compatibility=1;");
connectionStringBuilder.Append("Safety Options=2;");
connectionStringBuilder.Append("MDX Missing Member Mode=Error;");
connectionStringBuilder.Append("Update Isolation Level=2;");
using (var connection = new AdomdConnection(connectionStringBuilder.ToString()))
{
connection.Open();
}
}
This code throws the following exception
A connection cannot be made. Ensure that the server is running.
and inner exception says
Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
and inner exception of inner exception is
Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
On the other hand, I can connect to this Analysis Service from Excel with the same user name and password as shown below
I tried setting up HTTP access to Olap Server as described here. With anonymous authentication on IIS setting, I am able to connect successfully. But when I disable Anonymous option and enable Basic Authentication, again I am not able connect from my client tool but Excel is working fine with Basic Authentication.
But trying to use HTTP access was just for temporary solution. I do not want to use that option. I want to be able connect SSAS like I can in excel from my client app.
My question is, what is the difference between my implementation to connect SSAS (does not work) and excel authentication (works perfect) ?
Thank you in advance.
Instead of putting the user and password on the connection string try wrapping at least your .Open() function call in this impersonator:
https://github.com/OlapPivotTableExtensions/OlapPivotTableExtensions/blob/master/OlapPivotTableExtensions/Impersonater.cs
I have had more success with that than passwords on the connection string.
You shouldn't need the msmdpump HTTP layer unless you prefer it be involved.
Related
I am currently implementing a UWP program for an existing database. I took this article as a basis.
https://learn.microsoft.com/en-us/windows/uwp/data-access/sql-server-databases
When running, I get an exception:
System.Data.SqlClient.SqlException" в System.Data.SqlClient.dll
Exception:
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 25 - Connection string is not valid)
This seemed strange to me, since a WPF application with the same connection string works fine. Next, I decided to install a database instance on my computer and export some of the data to a local database. To my surprise, after replacing the connection string from:
Data Source=sqlserver\sqlexpress
to
Data Source=.\sqlexpress
UWP program read this from the database on my computer.
I also read this article to make sure that the remote database is configured correctly. https://www.lansweeper.com/knowledgebase/a-network-related-or-instance-specific-error-occurred/
As I said, WPF programs work with this database perfectly. What are the ways to check why the UWP doesn't want to communicate with the database?
to make it clear whether the remote server is available in principle, I apply the output of the TNC command:
tnc sqlserver -p 1433 -I detailed
ComputerName : sqlserver
RemoteAddress : 192.168.10.11
RemotePort : 1433
NameResolutionResults : 192.168.10.11
MatchingIPsecRules :
NetworkIsolationContext : Private Network
InterfaceAlias : Ethernet
SourceAddress : 192.168.10.20
NetRoute (NextHop) : 0.0.0.0
TcpTestSucceeded : True
Connection string look like:
private string connectionString = #"Data Source=sqlserver\sqlexpress;Initial Catalog=TestCatalog;User ID=*;Password=*";
The same connection string is used in VS. VS shows the contents of the table without problems. I can also delete or add new lines in the VS editor.
I'm talking about a remote database. In VS server Explorer I have a Data Connection where I am connected to a remote database. I can safely edit remote database data in VS (add, delete and update). I see the connection string and originally used it as the connection string in UWP app.
You have already taken a look at this microsoft link here. Long story short, have you followed the proposal below?
Trouble connecting to your database?
In most cases, some aspect of the SQL Server configuration needs to be changed. If you're able to connect to your database from another type of desktop application such as a Windows Forms or WPF application, ensure that you've enabled TCP/IP for SQL Server. You can do that in the Computer Management console.
Check to see if you have followed the rest of the solution properly. You might need to enable the tcp port from the window firewall.
Go to firewall -> Inbound Rules -> Add TCP:1433 in the rule.
Also since the error is about the connection string, try to use only the server name/ ip/ or hostname, without the server instance.
You can also add the port number and see if this works for you. When you add it, sql server ignores the instance name (as different instances require different ports to work, so it can work as a unique identifier).
Edit: How to create a valid connection string:
Look at this answer here: How to get the connection String from a database
I'm using "ServiceStack.Redis" to connect to Redis and it works correctly on my development machine.
Basically, I open the connection via this line:
client = new RedisClient(host);
Where host, on my development machine, is "localhost".
Now, I'd like to upload my application to Azure, so I created a cache in Azure and I'm trying to connect to it by passing the following connection string:
XXX.redis.cache.windows.net,ssl=false,password=YYY
The creation of the "RedisClient" seems to work but when I try to perform an operation (the first one to be executed being client.RemoveByPattern("...")), I get the following error:
Exception Details: System.Net.Sockets.SocketException: No such host is
known
Note that I allowed the cache to be connected to via HTTP, so normally, the port 6379 is unblocked and accessible.
All the example I found over Internet are using "ConnectionMultiplexer" but this class does not seem to be found in the NuGet package "ServiceStack.Redis".
What am I doing wrong?
I was having the same(similar?) issue connecting to Azure Redis with ServiceStack, in the end it was working out the correct syntax for the connection that worked for me. XXX.redis.cache.windows.net?ssl=true
Found some help here https://github.com/ServiceStack/ServiceStack.Redis, but to quote the connection strings section had examples;
"Redis Connection strings have been expanded to support the more versatile URI format which is now able to capture most of Redis Client settings in a single connection string (akin to DB Connection strings).
Redis Connection Strings supports multiple URI-like formats, from a simple hostname or IP Address and port pair to a fully-qualified URI with multiple options specified on the QueryString."
Some examples of supported formats:
localhost
127.0.0.1:6379
redis://localhost:6379
password#localhost:6379
clientid:password#localhost:6379
redis://clientid:password#localhost:6380?ssl=true&db=1
NOTE: I used the final example here but without the redis:// bit as I found this was not needed in Azure.
I am using the following code in conjunction with dapper ORM to connect to a database :
using (IDbConnection db = new SqlConnection(ConnectionString()))
{
return db.Query<object>(Sql).ToList();
}
The connection string contains database name and login information. I am wondering if while establishing connection to the database server, if any of that information could be visible to someone else.
If you mean in transit: you can force SQL Server to use encrypted connections - https://technet.microsoft.com/en-us/library/ms189067(v=sql.105).aspx
If you mean in-process - the key parts are removed by default so they won't be trivially available to other code with the SqlConnection instance; this is related to the "Persist Security Info" parameter on SqlConnection's connection-string, which defaults to false. Basically, the .ConnectionString property does not expose the credentials once provided. Note that the string will still have existed in memory at some point, so someone with raw access to the process and memory analysis tools may still be able to obtain it; see https://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring(v=vs.110).aspx
However, you could also just use Windows authentication via SSPI - this then just uses the app-domain's executing user identity info to connect. Same link as above, but see the "Integrated Security" connection-string parameter.
On the Local Computer: Yes, it would be possible to get access to the information
Over the Network DB Connections: Depends on DB, SQL Server supports SSL, but if you don't use that then you'd be exposing information in your traffic
This would entirely depend on where the connection is being established from and where the connection is being established to.
If either end is in the hands of someone for example, in a distributed client, then they will be able to get hold of the connection details. Typically however, a connection is established "behind the scenes", something like from a web server to a database. Because a connection established like this is all "server side", the connection string is never visible to the "client" of the application and is therefore generally perceived to be safe - of course it is still at the mercy of the infrastructure! :)
It's worth nothing that if this is something like a thick client running on a domain then using something like Windows credentials is an option and would be as secure as the account.
[edit] so not sure what happened, but we ended up resetting the server and turning off/on TCP/IP and Named Pipes and after a restart and updating the settings everything started working again. weirdest thing. anyways thanks for the help guys.
I'm building a C# WPF application for my job, and I'm getting a weird problem that I've been trying to figure out for the past week. The application connects to the server and imports several tables on start up. So I built it out and was testing it with no issues, but when i pass it to our testers, and everyone is getting the following errors:
Provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server
The users are able to connect to the server through other methods (SSMS/Excel VBA), but just through the application it won't work.
I've checked the following:
Remote connections enabled
TCP/IP connections enabled
Firewall settings are the exact same across all users (me included)
application is compiled as 32 bit (saw this in another thread)
We're using SQL Server 2008 and I've tried several connection strings/methods.
below is the code I'm using to connect:
public void Open_DB_Conn(string Connection_Str)
{
try
{
Sql_Conn = new SqlConnection(Conn_Str);
Sql_Conn.Open();
}
catch (Exception e)
{
MessageBox.Show(string.Format("Error Message:{0} Conn String: {1}",e.Message,Conn_Str));
}
}
Below is my connection string (this is just one of many iterations I've used trying to get it working):
Data Source=IP Address;Initial Catalog=DB_Name;User ID=LOGIN;Password=PWD
Anyone know why I would be the only one able to get it to work and that the users are able to login to the server using other applications without a problem? They use it for logging their excel VBA scripts and there aren't any issues there.
Try this - it may be your answer
"The error is reported by client library. While your server is listeing on remote TCP, client will still try TCP and NP connection in order. So the error client behavior is expected. From what you have described, I believe that even though you enabled the remote TCP connection on the XPSP2 machine, you didn't make the TCP listening port an exception of XPSP2 personal firewall. You should follow steps below to resolve this issue.
check the SQL Server Errorlog to make sure SQL Server is now listening on TCP/IP and confirm which port it is listening on. Usually 1433. In the Errorlog, you will see several lines that discuss what SQL Server is listening on. Below is an example:
2006-01-04 01:41:07.65 server SQL server listening on 10.254.1.150: 1433. <--Shows the IP Address and the port.
2006-01-04 01:41:07.65 server SQL server listening on 127.0.0.1: 1433. <--Shows another IP Address and the port.
2006-01-04 01:41:07.69 server SQL server listening on TCP, Shared Memory, Named Pipes.
2006-01-04 01:41:07.69 server SQL Server is ready for client connections
2, Make sure on Windows XP that the firewall is not blocking that port.
3, go to your client machine and run the client network configuration tool (cliconfg.exe) Make sure TCP/IP is enabled, click properties and make sure the port number is the same one as SQL Server is listening on. Here you can enable NP or disable client NP as well.
Once both the client and the server are using TCP/IP with the same port number and the firewall on server machines is not blocked, you should be able to connect.
Hope this helps."
(Ref: http://social.technet.microsoft.com/Forums/sqlserver/en-US/c488cf76-2515-440f-b3f8-9cfad689c5b6/named-pipes-provider-error-40-could-not-open-a-connection-to-sql-server?forum=sqldataaccess)
You have to configured your SQl server so that other IP can connect it for that you have to gone through mentioned link
Configure SQL server
What authentication are you using for the SQL Server? Windows Authentication or SQL Server authentication? My suggestion is to first turn on SQL Server authentication and use the sa\password to connect to the server. If you are successful, then ask the others (users of your application) to try with the same connection string. Let me know what you find out.
Be sure that the port specified in:
Data Source="IPAddress,port";Initial Catalog=DB_Name;User ID=LOGIN;Password=PWD
matches the port on your SQL Server. You can check that by going on SQL Server COnfiguration Manager and viewing TCP/IP properties.
EDIT :
It is also the case the port defined by blocked by an external firewall. And the rest Applications use other ports. Try to find out which port you can use (if indeed the are restrictions to your network)
Make sure your SQL Server instance is properly configured to use TCP using Sql Server Configuration Manager.
It is by default disabled in SQL Express, as show below.
I'd like to know more about your "Sql_Conn" class.
Also, try using this for your connection.
using (var conn = new SqlConnection(ConfigurationManager.ConnectionStrings["ConnectionString"].ConnectionString))
{
conn.Open();
using (var cmd = conn.CreateCommand())
{
string cmdText = "SELECT name FROM sys.tables"
cmd.CommandText = cmdText;
cmd.ExecuteNonQuery();
}
}
I've written a c#/.net program that accesses a Web Reference WSDL made in PHP NuSoap, that accesses a soap method through this call:
public kiosk_wsdl.MEMBER_DATA_RECORD record;
using (kiosk_wsdl.kiosk webService = new kiosk_wsdl.kiosk())
{
kiosk_wsdl.USER user = new kiosk_wsdl.KIOSK_WSDL_USER();
record = webService.GetMemberDetails("000000000001", user);
}
It works well in my localhost and our development servers, but when I transferred the NuSoap server to the production server, this exception occurs when I make the call:
The underlying connection was closed: An unexpected error occurred on a receive.
with the inner exception:
System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
While in this same production server, the method works well when accessed via a PHP NuSoap Client, so I'm guessing the problem is in my .NET client.
I've googled this problem and some say that it is possible that the server might have a default maximum message size configured to be too small, but how can I modify that in our production server? (and why does it work in our development machines where we have the same NuSoap configuration?) I've tried different solutions but to no avail.