I want to know how to connect Xamarin.Forms PCL with SQL Server directly. I know accessing the database directly will not be secured. But that's not problem in my situation. I need to access database directly from Xamarin.Forms. I am using Visual Studio 2017. I have developed an app with Xamarin.Forms PCL.
In answer to your question, use Entity Framework Core and a connection string, directly to your database. That will enable you to connect directly to it.
Now, I'm going to spend the rest of this answer, why you shouldn't do this
You are giving a remote, unknown, complete stranger, complete, direct access to your database. Even if it's in a separated network, with completely trusted users, and not on the app store, you are still opening your database up to potential security breaches.
It is likely over an unreliable mobile connection or wifi. It will fail and drop out, a lot.
It will be incredibly slow
If you want to move that SQL server later or update, you will break every single client out there, while you send an update for your app.
You won't be able to easily add any logic, in between, to improve performance, or add business logic as needed.
Database corruption, another important and likely to occur scenario, as mentioned by Brandon above.
What you need to do.
Create a web api. It's easy to setup one with WebAPI with dotnetcore
The API connects to the database, the mobile client connects to the API.
Add authentication to your API.
And I go into some more detail in Connecting to a remote database here.
Related
I'm working on a new personal project and I'm creating an App made in Xamarin and I want to connect it to an Azure SQL database.
My first question:
Should I create an API to handle the connection to the Database or is it enough to only use Enitity Framework with models?
My secound question:
How do I secure the database password, is it safe to keep it in the appsettings.json?
Thanks!
Yes, you should create a REST API and expose its endpoints that your application can interact with. There're tons of reasons why you should NOT connect directly from your client application. You can review them in this answer: https://stackoverflow.com/a/13471874/12128089. In a nutshell the most 2 important are:
Speed: Handles connection to a remote database with limited memory, can kill your application.
Security: Frontend applications, in general, are vulnerable and attackers can obtain credentials of your database, and if your permissions are set up wrong, they could wipe your database.
Is it possible to create multiple backplanes within Signal-R?
We're working on an ASP.net WebAPI Sass application and are looking to implement Signal-R for "real-time" web functionality. Since we'll be hosting the application a web farm, client-connection state will be managed through a SQL Server backplane.
The application is multi-tenant - but database is not. The application determines which connection string to use and all client requests talk to their appropriate database. Now the code for configuring the Signal-R SQL Server backplane within Application_Start() is:
GlobalHost.DependencyResolver.UseSqlServer(connectionString);
Does anyone know if it's possible to create multiple backplanes with Signal-R, basically loop through each connection string and call the above code?
Thanks for checking this out!
If you need to eliminate the single point of failure, I suggest setting up a failover server in case the primary SQL Server machine goes down. Reference: http://technet.microsoft.com/en-us/library/hh231721.aspx
If you simply need more performance than a single SQL Server instance can provide, I suggest using Redis as the backplane.
In either case, I doubt attempting to use "multiple backplanes" will be helpful, unless you intend to map certain hubs to certain backplanes for load distribution.
My company is planning to turn an older Winforms application into a WPF/Silverlight Client/Server app.
The idea of having a small server app is to have a list of the accessible data bases combined with the user type that may access each of the databases, instead of having to manage databases in each client's admin control. Additionally, it would be great if the SQL request would be handled by the server which would then return the result.
The app is supposed to work on a arbitrary set of databases which will be "registered" with the server and users get a list of databases according to their authentication rights. They can then do practically everything on those databases what one can imagine. The system should be able to handle up to 2 million rows.
The databases are very different, there can be many of them, they can be MS Access, Oracle, SQL Server etc., so no way for me to specify them all before. On top of that, communication with a SQLite cache is needed.
I already have everything I need for the SQL queries from the Winforms app.
I was thinking:
1) A simple WCF server specifying in a config file the available databases per user type.
2) Interface that specifies all necessary SQL queries that can be made to the server.
3) Client...
The idea is:
a client-server application, where the client uses WCF services to execute SQL queries (INSERT, UPDATE, SELECT, etc.) on tables by invoking services methods.
The service should ideally be consumable for both the WPF and the Silverlight app.
Is that the way to go? Which exisiting technologies might I want to make use of regarding formats, communication, services etc.
If that is problematic, I would consider going back to a desktop app, but then how to ease the user type/database access problem for each client?
I would stick with ADO.NET and start with the DbProviderFactory class. This will let you determine the proper database access based on information supplied by the provider using the Factory Design Pattern. So instead of having to create a specialized objects for each database type and database, you can abstract that logic with the DbProviderFactory.
Here's a link that shows some examples: http://msdn.microsoft.com/en-us/library/wda6c36e(v=VS.100).aspx
So I'm inexperienced in hosting DB's and I've always had the luxury of someone else getting the db setup.
I was going to help a friend out with getting a webpage setup, I've got experience in Asp.Net MVC so I'm going with that. They want to setup a search page to query a db and display the results. My question I have is in getting the DB setup and hosted. They currently just have the Access DB on a local computer. There is basically only one table that would need to be queried for the search.
What is the best approach to getting this table/db accessible? They would like to keep the main copy of the db on the local machine, so copying the entire db over to the hosted site would be time consuming, could the lone table needed be solely copied to the host? Should I try to convince them to make changes on the hosted db and just make copies of that for their local machines? Any suggestions are welcome, Again I'm a total noob when it comes to hosting databases.
Thanks
Added: They are using a MS Access 2000, and the page will have access restrictions. Thanks for the responses.
How about SQL Server Express? I think you can do a remote connect from Access and just push the data over from Access.
I wouldn't use Access on a web server in any case.
I would strongly recommend against access from web work, its just not designed for it and given that SQL server express is free there is no reason not to give it a go.
You can migrate the data over by using the SQL server upsizing wizard, here is a link for help on using that feature
http://support.microsoft.com/kb/237980
It depends on what you mean by web work? Access 2010 can build scalable browser neutral web applications. They can scale to 1000's to users. In fact, you can even park the web sites on Microsoft's new cloud hosting options, and scale out to as many users as you need.
Here is a video of an application I wrote in access 2010. Note how at the half way I run the same application including the Access forms in a standard web browser. This application was built 100% inside of the Access client. The end result needs no ActiveX or Silverlight to run.
http://www.youtube.com/watch?v=AU4mH0jPntI
So, the above shows that access can now be used to build scale web sites (you can ignore the confusing answers by the other two posters here they are not quite up to speed on how access works or functions).
However, for your case, I would continue to have the access database on the desktop. You can simply link to tables that are hosted on the web server. Those tables can exist in MySql, or sql server. As long as the web site supports external ODBC connections (many do), then you can thus have the desktop application use the live data from the web server. If connections to the live data at all times is a issue, then you could certainly setup something to send up new records (or the whole table) on some kind of interval or perhaps the reverse, and pull down new records on a interval from the web site (depends which way you need to go). So, connecting to MySql or sql server is quite easy as long as the web hosting and site permits external ODBC connections. I do this all the time, and it works quite well.
As mentioned, new for access 2010 is web site building ability but that does requite Access Web services running on SharePoint.
You don't need to upgrade to Access 2010. One option is to use the EQL Data plugin to sync the database up to the server. Then you can write an asp.net, php, or whatever application that queries the table using the EQL API and prints the results however you want. This kb article describes how to use the EQL API from a web app.
The nice thing is that the database is still totally usable (and at full speed) even when you're not online, and then you can sync the new data up to the web occasionally. It only uploads the changes, not the entire database every time, so it's fast.
Disclaimer: I work at EQL Data so I'm a bit biased. But this kind of use case is the whole reason the company exists.
We upload sales transactions from our stores to the headoffice server. At the moment, we use DTS (SQL Server Data Transformation Services), but we’re planning on replacing that with Microsoft Sync services for ADO.NET, as this seems to be Microsoft’s preferred solution for this type of setup and we want to follow the standard (that will be hopefully be around for a long time).
Here are the details of our setup and what we’re planning. I’m looking for some advice, especially about whether Sync Services fits into our solution.
Situation
Each store has a 3rd party EPOS system which stores sales in a Microsoft Access 2000 database, which we can access. Our headoffice database is SQL Server 2005, but will be upgraded to 2008. The headoffice is not on a VPN with all the stores, but we can open up our firewall to the stores’ IP addresses, so that they can send data directly to SQL Server. The stores are always connected to the internet via ADSL, although they do lose connection and we don’t want to lose sales data.
We are only uploading transactions from the store – definitions do not need to be downloaded.
Current solution
We have written a Windows service that runs on the store PC. This service downloads a DTS package from the server (which contains all the details of the upload) and runs it in the store – and this will upload sales to our server.
We chose DTS, because it is free when you install MSDE. We can’t use SSIS, because that would require a SQL Server licence at every store.
Another reason we chose DTS is that the details of the upload (i.e. which tables and fields to include) are stored on our headoffice server, so if we need to change things we can do that centrally and don’t need to install anything new at the stores. This isn’t a showstopper, but would be nice to have this ability in our new solution.
Potential solution - Microsoft Sync services for ADO.NET
We are currently building a proof of concept with Microsoft Sync services for ADO.NET. The idea is to put SQL CE (SQL Server Compact 3.5) in each store (client) and sync that to the headoffice SQL Server 2005 database (server). We’ll get the data into the SQL CE database either by (1) syncing it with the Access 2000 database or (2) getting the EPOS system developers to write sales straight into the SQL CE database – probably (2). But our main concern is getting the data from the store to the headoffice server. This method seems to be Microsoft’s preferred solution for occasionally connected systems and that is what made us look seriously at Sync Services.
I’m hoping that using this will mean that most of the work needed to upload the sales will be built into Sync Services and we won’t have to re-invent the wheel.
Potential solution - Upload to a custom webservice
There is also the possibility of uploading the sales transactions to a custom web service on our headoffice server and then into our SQL Server database. This means that we will have to build our own mechanism for determining which rows are new, and as well as caching for when the systems are disconnected. Also, we might be missing out on other functionality that will come built into Sync Services.
Please let me know if you have any advice that will help, especially : “Is Sync services the right solution!”. The problem that we are trying to solve seems very generic (uploading sales from stores) – and I’d like to solve it with a generic solution.
Microsoft Sync services is more than you need, but it will certainly do what you want, and it was built with your type of application in mind.
As with most new technologies out of microsoft, (caution: generalization!) you may find that it's not as mature as you might like. It'll do what you need it to, but you may run into issues that aren't easily resolved because it hasn't been put through the ringer. As an early adopter, though, you may find that the Sync developers are eager to help you out when you get stuck, so this isn't as big a problem as it might seem.
Make sure you read through all the literature on it, some of which is here, or linked in the following sites:
http://msdn.microsoft.com/en-us/sync/default.aspx
http://msdn.microsoft.com/en-us/sync/bb887608.aspx
http://en.wikipedia.org/wiki/Microsoft_Sync_Framework
Given your one-way flow of information, though, and centralized layout I expect you should have few, if any, issues setting it up and using it.
Be sure to report your experience back here!
-Adam