We have the following set up:
Windows Mobile Device with GPRS connection
Windows Server PC with SQL Server 2012
VPN Network where both devices contained (the cell carrier routes certain IPs inside VPN)
Status:
With the above set up I can ping directly from the mobile device to Windows server internal IP via GPRS.
Question:
Can I create connection to SQL server from my Mobile using the server's internal IP?
My con string is:
"Data Source =xxxxxxxx,1433;Initial Catalog=xxxxx;Integrated Security=SSPI;User id=xxxxx;Password=xxxxx;Connect Timeout=15"
EDIT:
More Questions:
How can I implement it if yes
What are the pros and cons in accordance to David's comment
If you have a VPN and can ping the internal server then you can connect directly to SQL Server using the normal data access libraries available in the .Net Framework. Having said that, I would strongly advise against it. It's much preferable to have a middle tier service that interfaces between the mobile device and the database. Here are some reasons (off the top of my head) why this is better:
Mobile connections are inherently unstable and SQL connections are not great at handling that.
Having a service means you don't even need a VPN as it can be public facing (with relevant security of course).
If in future you decide to move form SQL Server to DocumentDB/Azure/carrier pigeon, then you need to update every single mobile device to cope with the change. If you have an intermediate server, you can just update that.
If database schema changes, you may break all of your client applications in one go.
Your middle tier can do other useful things like caching, logging etc.
Related
I'm trying to make a login app.
I would like to know how the connectionString on app.config is made for an online connection and if I would need anything else to reach the database, being as I'm trying to go directly to the user table on that database and perform a check for the login (as I already made it happen with a local database)
Best Regards
Your online database, does that mean a database at a remote location?
I would advise against going directly to a remote database unless that database server is protected in a LAN environment with no outside public access. Public access would also be considered if users inside the LAN also have unregulated access to the remote server. In any thick click based application the typical architecture would be to go through a proxy source or set of WebServices to authorize and authenticate users. Direct access opens your SQL server up to remote attacks.
That being said the connection string to an SQL server (remotely) could be:
Standard User\Pass
Server=myRemoteServer;Database=myDataBase;User Id=myUsername;
Password=myPassword;
Now chances are there are firewalls between the remote database and your client APP protecting remote logins (as there should) and it is a good possiblity that SQL server has disabled remote logins. Read here for more http://blogs.msdn.com/b/walzenbach/archive/2010/04/14/how-to-enable-remote-connections-in-sql-server-2008.aspx
I must point out again that this is a very bad idea and I would personally create a set of WCF WebServices to run on the server with the database. The WCF services would be responsible for connecting to the database to verify the credentials and return a structured datamodel.
WPF Applications are designed to work really well with the Async methods of WCF services and are very simple to setup. Using this model you can also setup more advanced layers of authentication using hashed token sets, implement SSL to block sniffing out the plain text, and keep your database protected from external access.
There are alot of examples on the web to connect to WCF services from a WPF application.
Please actually read my post before placing it on hold!!
Let me start by saying I've been searching for a solution all afternoon and so far I have seen plenty of examples for WCF but none that would do what I need.
I have developed an application in c# that will be installed on customer servers and accesses a sql server on the customer's local network. The application also has the ability to control network relays on the customer's local network and records the status of these in sql. I am trying to figure out a way to have the customer's server establish a connection to our datacenter and be able to issue commands back to the customer's server (retrieve datasets from sql, control the network relays, etc). I have found plenty of ways to have a client call classes on a server but have so far been unsuccessful in finding the reverse. One consideration was writing a web service as part of the application on the customer's server but need a way to establish this connection for customers with dynamic IP addresses and without having to publish through firewalls, etc.
Have you considered using
VPN - Virtual private network
or
Configuring a Port Forwarding redirect on the ADSL modem, and using a solution like www.noip.com ?
If I understand correctly you want to get information from the customer's database, which is behind a firewall and has no known static ip, in addition there might be several hundred customers so a dedicated VPN to the customer is not viable.
First of all: you should not contact the customer database directly. Databases are not designed for this scenario and would probably be left open to attack if exposed directly to the internet.
So you need a service on top of the database. There are two main options you can use for this service:
Polling service
The service is actually a client calling some web service on your network and asking for instructions.
Benefits: easy to implement and deploy.
Downsides: With polling there is always the cost-benefit of scalability/bandwidth use vs. speed of service. There are also some considerations in selecting the time to poll to prevent all the client polling at the same time.
The service is a tcp-server
This can be a usual web service (or RESTfull service) or some other service. The only difference is that it needs to advertise itself. For that you need to have a known directory server. When the service starts it then connects to the directory service and tells it the port it can be contacted on (the directory knows the ip from the connection). It will then need to periodically contact the directory to let it know it is still alive and so any change in IP is detected.
A client on your network would now query the directory to find the address of the client and connect directly to it to issue commands.
Benefit: Scalable and bandwidth efficient.
Downside: More difficult to implement. Requires firewall traversal solutions (UPNP or firewall exceptions).
I am have tremendous trouble with this.
What I want to do is: I want to create a system (in C#) that will (amongst other things) allow users to send simple messages to each other. So I want to create a MySQL database which will rest on a server. Other computers running the system will then have to connect remotely to this database and read a certain table to see if they have any new messages.
I want the client computer to connect via the internet to the database on the server.
But how do I do this?
How do I create a database that can be connected to through the internet?
How should my connection string look like on the client computer?
What configurations do I need to do on both client and server computers?
Any assistance is deeply appreciated, and if you could suggest how I can go about achieving my objective. I am a quite competent programmer, but HATE these network things!
I am developing in C# using WPF to access the database. So it's a desktop app!
Here's how you do what you're asking to do.
Use the MySQL Connector/NET ADO.NET connector. It is here.
http://dev.mysql.com/downloads/connector/net/5.1.html
Follow the directions for setting it up. It works very well.
Put your MySQL server on a public IP address.
Get your client software assembly to connect to that public IP through the ADO.NET connector.
But, PLEASE!
Ask yourself whether this is the right thing to do. It probably isn't, because MySQL servers (and all table servers) work much more safely and predictably when they are behind firewalls and accept connections from a limited number of client packages.
Consider doing what Mike Christensen suggested. Use ASP.NET and WCF, or whatever stack you like, to build a server-resident interface to your MySQL database. That server-resident interface can then be accessed by the client software you push out to your end users.
That interface can have just the methods you need. WCF or any other stack for building server components can do this easily and robustly. For example.
Client 1: This is moe. Here's a message for curly: "Look at the grouse, look at the grouse".
Server: OK
Client 2: This is curly: any new messages?
Server: moe says "Look at the grouse, look at the grouse".
Client 1: This is moe. When did curly last collect my messages?
Server: ten minutes ago.
Client 2: This curly. any new messages?
Server: NO
This is far safer and more scalable than just making the MySQL interface available on the internet, and it will perform much better.
By the way, it looks like you want an instant messaging protocol. You may want to look into using the open-source system at http://jabber.org . This stuff can be tricky to get right if you build it all yourself.
I have a issue where an application I am writing (written in .net using C#) has started to be blocked by the firewall when making SQL connections, the reason seems to be the inbound port client side is coming in on a massive range that isn't allowed by the firewall (around port 50,000 - 60,000).
Is there a way to make SQL connections run on a specific inbound port range client side so this smaller port range can be added as a exception to the clients firewall? The server uses Microsoft SQL Server 2008.
I know one solution is to add the application itself to the firewall but the delployment method used at the company is Click Once and when it updates it changes the directory of the installed program meaning an admin has to update the firewall for each client every time an update is made.
As I pointed out in my comment (quoting myself here), you might want to consider moving the queries in a web service, and let it provide you the data (it'll be deployed on a specific, well-known port, so you'll be alright).
More on the subject: I strongly recommend you never allow the outside world inside your corporate database, it's a big security issue.
I have a little .net 2.0 systray app (C#) that checks for network connectivity periodically. It does this by attempting to open a connection to a SQL-Server instance on another computer (and selection a row from a table). The application saves documents created by another process to a database when it finds a connection. It is going to be used in environments with potentially dicey wireless networks.
In testing our QA team is using ipconfig /Release on the DB server (hosting a Sql-Server 2005 DB). What we found was that the application continued to claim it was network connected, because it kept right on successfully opening connections to SQL Server. I found the systray app's behavior erratic in my own testing using ipconfig /release.
At the suggestion of our not-currently-present network guy I changed my own internal testing (app hosted on a VM, connecting to DB on my workstation) to instead turn off the VM network connection. This produces the expected behavior (the systray app can't find a network connection). The QA guys are a little leery about my suggested that they do the same, and I need to put them at ease.
It was suggested to me that SQL Server was using named-pipes to accept incoming connections. If Named Pipes and TCP/IP are enabled, does this invalidate the ipconfig /release test?
I don't really know much about networking. Named-pipes, according to what I have read, sounds like it is designed for use between applications on the same server. But it can be used for intranet communications?
Is there something else going on here that I an unware of? Something about how ipconfig /release works
For your application, I would only use TCP/IP communication protocol. Although SQL Server supports other communication protocols such as named pipes, I would disable them on your server so it only accepts TCP/IP connections. This is least amount of overhead and should perform the best regardless of connection speed.
Named pipes is a different protocol then TCP/IP, so releasing the IP address may not effect named pipe communication in any way (Sounds like it is).
On the SQL Server machine, put TCP/IP as the number 1 protocol and disable named pipes. The have QA re-run the test. I have included a configuration screen shot for reference.