This is outside my usual domain so please forgive my ignorance.
I am developing a Windows(7) plugin in C# for a local application that will query a database, returning the results to the application(simple). The issue is people can work from home so if I use a MS SQL Express database (as I usually would) it would be exposed on the internet and I have read an MS SQL server exposed to the internet is often compromised quickly.
I could install the database with the plugin, but I believe that would make managing the database, updates and troubleshooting a nightmare as there would be 15 separate deployments.
Can anyone suggest approaches to take to have a plugin for a local application that queries a remote database and is not a massive security liability or speak to the security of an internet accessible sql express delpoymeny?
Thanks
First post on stack overflow, I did search for answers prior to posting.
Usually you will want some type of web services layer between your database and the remote clients.
In this case you would have a web app that exposed certain service calls. The calls should require some type of authentication and perform the necessary actions on the database.
Related
I have some Databases built in Access and I want to be able to view and edit them when I'm not connected to a local server\network.
How can I access with C# to view and edit the Access databases placed on a server without VPN or SMB (which means creating local network). Is it possible to edit it realtime on the server?
This needs to be accessed by more than one people, thus I also want for example block a table if one's already editing it (so here also goes the FTP protocol - to download and edit on the PC and reupload)
I hope I was clear enough and provided enough info, thanks for all helpers!! Enlighten me please :)
We would first have to ask how end users going to run and use the C# program?
Desktop: users would need a network connection to the server. (most likly a VPN).
Web based: users would need a network connection to the WEB SERVER. This could also be a VPN, or could be a web server that is public facing. this would then require logons for security.
If users don't have a network connection, then it not going to matter if this is oracle, MySQL, SQL server or Access. And in fact, if this is web based, then users need to be able to connect to that web server.
So, without some kind of network connection to that server or computer where the data resides, and you eliminated a VPN, then your options are limited.
You can build a web site and place it on a server. However, if users don't have any kind of network connection even in the case of a web site, then I fail to see how you can even suggest using FTP let alone any other kind of connection.
This needs to be accessed by more than one people,
Ok, you need multi-user. However the locking up a whole table on sql server to allow only one user is actually quite difficult.
But, we can leave that you want one user in a given table at one time. (but both Access and a web site would in fact allow multiple users - even editing the same table).
All in all?
Then this suggests the most obvious solution: run a web server, and that would allow any user to connect to the web site, and the web site then can read/talk/use the access database that resides on that server. And this then again means that you don't need any client software installed.
FTP is not a practial solution - since it only works on a whole file.
So, users will require some means to connect to some server. That being the case, then write your C# appliation as web based, and thus no client software will be required, and the only software that interacts with the access file on that server will be the web site.
So, running a web site on that server does seem to be the best option.
So, we heading towards a web solution.
So then software would stay and run 100% on the server side, and thus zero client software would be required other then that of a browser.
I developed a simple Python web server to work with the Access DB via HTTP:
https://github.com/vikilpet/MS-Access-HTTP-Server
Probably this is not an ideal solution for your case but it may be a good starting point.
I have created two applications using Visual Studio and C#.
The premise of the applications is for data entry and browsing of the data. However, I have come to the realization that these applications won't work on other devices as the data source is a local Access database. Am i able to somehow share these apps with others without giving them the Access database too? This is a major problem as my boss only wants these apps and not the database to be sent with them too. Or would I have to migrate the database to an SQL server and try to migrate the application as well?
Thank you
TLDR:
Can Access database applications be shared across desktops?
Yes
Am i able to somehow share these apps with others without giving them the Access database too?
Yes
Or would I have to migrate the database to an SQL server and try to migrate the application as well?
Not necessarily
It's a difficult question to answer because the question seems slightly confused
You've created an app or two that enters and shows data in an access database, and now you're asking if the app can be distributed without the Access database
Sure it can; but what then will be the purpose of the the app?
You ask if it could be switched to using sql server instead.
Sure it can, but I'm not really clear on how you think it will help because you then have to install sql server in the customer premises and give them the database. I suppose you could keep the sql server on your premises and they could connect to it, but then you could just as easily create a web service or API that sits in front of your access db and have your programs interact with the API, as a way of keeping databases off the customer premises and then stick with Access (or change it later and not affect the customers because you're providing the same api which a new db).
It's most typical, when having software that customers use and a database that you keep ownership of, to separate them with an api
As an aside, Access is terrible in a multi user configuration where two different apps are trying to use the same db file I've a file share; take any steps you can to avoid using this scenario
Stackoverflow is designed to answer particular kinds of questions and there's a real risk that this question will stray into opinion based territory and become off topic. We can't design your app for you, we can only help with implementation problems but it sounds like you need to sit back and think some more about what you're trying to solve for the problems your customers face, and see if you can get some help regarding the tech stack you should look to implement. If you desire SO to deliver these answers you'll need to ask them in a particular way, essentially having made a set of decisions yourself and be missing some facts that will drive the implementation choices - ask us for the missing facts rather than to make the implementation choices
If all the clients apps are on the same network and can see a central server, then there's no reason you can't use the Access database in the same way you would a SQL Server database, i.e. by placing it somewhere where it can be accessed by all copies of your application. Access isn't the last word in database features or security, but it's perfectly workable.
We normally create a mapped drive on the client PCs to a location on the server, so that everyone can use the same connection string for the database, e.g. T:\yourdatabase.mdb.
If the clients aren't on the same network and you can't use a VPN to connect them then to single network then things will become a lot more difficult, and moving to SQL Server will probably be a lot simpler.
Essentially, if this is an in-house system where the data isn't too sensitive and all the users are members of staff say, then a central Access database can work fine. If this is an app that's being used by people outside your organisation then SQL is a better choice if you want your app to talk directly to the database.
Alternatively you could write an API that you host on a web server, then your client apps can talk to the API and your API can talk to the Access database.
I have developed a simple desktop application with a SQL Server database for a single PC and now the client want to make it work on multiple PCs. I want to know what is better: for the moment I have remote the database from sql management and all application just connect to it. Is this a good idea or do I have to do some modification to improve the executing of the application?
The database has a lot of information to be imported to the application.
I don’t have a good idea about WCF but would it help to read about it?
You could have a dedicated server with database hosted on it and all the client applications could connect to it. But one thing you have to take care of is transaction management that is while a user is updating some piece of information, no other user could change that piece of data to make that data inconsistent. You could a look at this post describiing Sql Server Transactions.
Depending on the requirements I'd recommend keeping the local database as cache for speedy application start and implement a synchronisation process where the local and remote databases are compared from time to time or triggered manually by the user.
This would be very similar to how for example IMAP email clients or Evernote works.
How can I make a program use a SQL Server database, and have that program work on whatever computer it's installed on.
If you've been following my string of questions today, you'd know that I'm making an open source and free Help Desk suite for small and medium businesses.
The client application.
The client application is a Windows Forms app. On installation and first launch on every client machine, it'll ask for the address of the main Help Desk server.
The server.
Here I plan to handle all incoming help requests, show them to the IT guys, and provide WCF services for the Client application to consume.
My dilemma lies in that, I know how to make the program run on my local machine; but I'm really stumped on how to make this work for everyone who wants to download and install the server bit on their Windows Server.
Would I have to make an SQL Script and have it run on the MS SQL server when a user wants to install the 'server' application?
Many thanks to all for your valuable time and effort to teach me. It's really really appreciated. :)
Edit:
To clarify, each business will have their server completely separate from me. I will have no access whatsoever to them nor will they be in any way connected to me. (I don't know why I should clarify this :P )
So, assuming the have ABSOLUTELY NO DATABASE SERVER installed; what can I do?
Ok, part of the answer, dealing with the SQL Server Database (and frankly SQL Server Express will take you a long way - 4Gb of data) and the server install elements.
Firstly make installation of the SQL an SEP, make it a pre-requisite possibly tweak your installers to test (challenging) but substantially point them at the links to SQL Server express and let them get on with it).
Secondly separate installers, as suggested, for your client and your server elements.
Finally, how to build the database - I'd suggest using code to create and maintain (update) the schema i.e. once you have a connection to a server you can run code that calls DDL that does what is necessary (something like suggested here: How to create "embedded" SQL 2008 database file if it doesn't exist?)
A question - are you intending all communications from the clients to go through you WCF service?
Your install application should:
Obtain a SQL Server name, a username (with apprpriate rights to create a database) and password.
Either run SQL scripts using the locally installed command line tool or from code using SMO (for instance), against the user supplied server with the supplied credentials.
BTW, Before you expend effort writing an open-source help desk, have you checked what is already available? Also, Open Source Helpdesk
It is not so straightforward to deploy a client/server solution with an automatic installation.
You probably would then be better off to deploy your server installation together with a database engine and a skeleton database already setup according to your wishes. This is to avoid tampering too much with the existing server - who knows whats on it.
Also you say you want to install WCF services, well this would probably mean installing them on a customer server, in theory this shouldn't be a problem however in reality it could be, depending on what is previously on the server.
Do you want a single SQL Server instance running on your machine, or one on each of your customers' servers? If it's the latter, you'll want to install a SQL Server instance - anything from the (free, but limited and not open-source) SQL Server Express to a more expensive SKU - on each server. You can include this step in your server installation package; MSI installs make it very easy to bundle a MSSQL install.
Then you'll need to drop a schema, and maybe data, on the instance. You could do this as a step in your installer, or as part of your application setup process. It possible that a SQL Server instance, or more than one, might already be installed on the server, and your post-install step should allow the user to specify which instance on which to install your pieces.
Then, include a database configuration piece in your client application. Ask the user - or take from a configuration file at client install time, to allow for unattended or unprompted client installs - server connection details, like server name and authentication information.
A word on authentication - since you appear to be building Windows-based tools, use Windows integrated (domain-managed) authentication if at all possible. Don't get in the business of storing logins, but instead rely on the existing domain to manage logins. A good strategy is to use active directory groups to manage access. Grant access to a particular group in SQL Server, and defer group membership to Active Directory itself. If you can't gain the access necessary to do this, then grant permissions to AD user accounts themselves. Avoid creating SQL Server logins, the use of which open the door to some possible security problems.
I understand what you are trying to do. If I were you, I'd do the following:
Provide 2 downloads - 1 for client and 1 for server.
Forget about MS SQL Server and perhaps go with MySQL, since it really is open source. You could probably get away with using MS SQL Server Express Edition, but if your data set gets gigantic large (which is common with help desk databases), you'd be stuck.
As other people pointed out, on very first run (or at setup time), I'd have the client app locate the server.
I have a few ASP.Net database front-end websites where MS Access is the back-end. I am trying to use ASP.Net dynamic data website. Should I change this database to SQL Server Express or something else to make it easier or should this work from with MS Access.
Pick SQL Express for these reasons:
Scaling: MS Access will never scale. Once you get over about 10 concurrent connections you will start to see trouble. SQL Express will scale. You can always move SQL Express up to a full-blow SQL Server installation. While this is somewhat true of Access, some of your SQL statements and data types may not transfer cleanly.
Security: SQL Server has a much better security model than Access. You can lock down the schema in your db per user. You can also better administrate user access (think dev user vs test user vs production user).
Performance: This is similar to scaling. If you see a traffic spike to your web site, Access may not handle it while SQL Server Express probably will.
Tools: Tools and libraries like LINQ are always going to be targeted at SQL Server. You will get better support and better documentation using them this way.
A Jet back end will work fine for mostly read-only websites, even ones with decent traffic. Michael Kaplan's old website, http://trigeminal.com, uses a Jet database as the back end, and back when it was his primary site (he's since been hired by Microsoft), he said it was getting over 100K hits per day, and was holding up just fine.
For read/write operations, Jet will begin to bog down on a website about the same place it would bog down in a multi-user LAN application, at somewhere between 20 and 50 simultaneous connections, depending on your app's design.
For what it's worth, even though I'm a professional Access developer and know Jet very, very well, I don't use Jet as a back end for any of my websites. That's not so much because I don't like Jet for websites, but because I don't like Windows for a web server -- I'm an Apache supporter (and PHP developer), and host all my websites (and my clients' as well) on non-Windows hosting services (presently all of them are Linux, but that wasn't always the case). All the website databases I have ever done use MySQL for the back end.
In short, find out what your host offers in terms of database back ends and choose the best one. I can't imagine a host that provides ASP.NET that would not offer SQL Server, and that's definitely what I'd go with in that situation. It would be easy enough to upsize your Jet back end to SQL Server on your local PC, and then do a backup that you could import to your website.
You can use LINQ to DataSets to use Linq against an Access .mdb or .accdb database.
You can read more at http://msdn.microsoft.com/en-us/library/bb386977.aspx and http://blogs.msdn.com/adonet/archive/2007/01/26/querying-datasets-introduction-to-linq-to-dataset.aspx