I have the local database in SQL Server 2014 with four tables volume 1.5 GB. The essence of the program to look for in the database records with the user defines criteria. The program is written and it works fine. We should make sure that the program worked and other users who have not installed the server. How to implement this? Was a idea to serialize the data, but as I understand, it is necessary to deserialize all the data and then look for the right record.
As the comments before me already says i think you have 2 options.
Either ship the database with the client (using Sql Express or other similar solutions). That should work fine and will work without a connection to a centralized server but the size of your client package will be quite big. And if you make any changes it will only be locally, but it seems you only make reads to the database from the client?
But if i understand it correctly you install a sql server for each client, since you mention "users who have not installed the server"? Then you already have the problem with a lot of data needing to be sent out to each client, as well as the problem of updating all databases when the data needs to be refreshed.
Another solution is to allow access to the database from the client. This can work in serveral ways, if all your users is in your doman you can handle authentication based on their domain users and skip the authentication part. Then you would only need to send out the client and skip the installation of a big server and all the data.
If they are not on the domain but still on your network you could add a login on your application to allow access to the database or if you trust all your users you could add a read only account and just hardcode the login for that account.
If you want to access the data outside of a trusted environment you should of course add a separate login for each user to allow access and it might even be a good idea to use an api before the database that handles the requests from the client and then does the search to the database in a controlled manner.
I would personally go with using a centralized database to skip all the work of setting up new users and also have a single point to update when the data needs a refresh, but of course it all depends on where your users are.
Related
I couldn't find proper topic so I'm creating this question.
I'm building an Desktop application that is running on data from MS SQL Database. Most of the data there is updated once a week/month, and most of the tables are read-only to end user. I figured, there is no need for the user to work directly on SQL Database online and in order to speed up the performance, I want the app to download necessary data from SQL Database on start, and then use localy saved data + in case of server outage user should be able to load app using latest saved data.
The thing is, data needs to be encrypted and secured from unauthorised use. I used to have SQLite database, but running on two databases doesn't feel efficient.
What solution would you suggest?
The problem with encrypting is:
1 - you need to decrypt in order to use the data in your application, which will have a performance impact.
2 - if you can decrypt, so can someone who has obtained the data illegally so it's not really that secure.
If you did want to go down this route, you could read in the data from the DB, decrypt and then cache it, which will speed the application.
The cache could last for several days based on the fact you said it only gets updated every few weeks/months and minimise DB calls
I am not sure your proposal is a great solution.
You have data that a user should not have full access to; so you want it encrypted.
The easiest way to limit access is to not give the user access at all; for example by putting a server in front of it. The server can only talk to the database and the database is secure and encrypted etc.. now you don't need client side encryption (which can always be broken if a hacker has enough time and money). You just secure your server and expose some API's and boom, you are secure.
But let's find out a bit more about your data. The client of course needs to view the data in the app, but isn't allowed to have access to the database when running locally. Why do you have data in the local database that the user isn't allowed to see in this case? This sounds like a security issue where a user might have (private) data of your company or other users on their pc, which you do not want, ever. So let's say we only store data on your pc that the user can see in the app anyway. Security is better now!
Now to solve the problem of performance. How much of a problem is it? You could implement caching in the server and client, depending on how performance problems you have. When the server only returns data that the client is allowed to see, you could cache it in the client and also on the server.
If the client already has data cached and doesn't need to retrieve new data (when is this?), Then it doesn'y need to talk to the API. and if the client doesn't have data or has outdated data, the API checks if it has the new data cached and returns it immediately if so.
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 wrote an application in c# & SQLite for storing data of all employees in a company which has around 500 employees. I want to put the database & the application in a file server/shared folder (MS server). Then all employees will have a shortcut of the application in their desktops. I want to make some input fields (text box) enabled/disabled based on the permission of the user runs the application. Whats the best practice for doing that?
I want the user can read/write in the database through my application only (the application is located in the same database folder). I don't want the user to reach the database without my application. How to do that?
I don't want the user to reach the database without my application
If your application will directly access the SQLite database via a Windows file share, this is impossible. Sure, you can make it inconvenient, but it's not really possible.
The only way to achieve this really is by introducing some middleware.
This would typically be a service (WCF perhaps) that listens for connections from your client application, authenticates them, and manages all access to the underlying database. The database would be stored in a location that is visible to the server only, and not visible through a Windows share to your users.
Also, SQLite isn't exactly a great choice for a multi-user system. You can kill two birds with one stone here - switch to a DBMS (MS SQL Server Express is free, also MySQL, PostgreSQL are common free choices) that accepts client connections over a network, and build your application to connect directly to the database server (using integrated Windows authentication may also be possible like this, so you can avoid an explicit logon). In a simple scenario this may be adequate and avoid you needing to build an explicit service layer.
In a more complex scenario, it can still make sense to have a middleware layer between the application and the database - this way, you can change the database design without changing the application design and deploying to all of your client machines - instead, just change the middleware layer in one place and your application won't know the difference.
If you don't want the users to reach your database you should create a client server architecture.
You can run your service on the same machine as the file server (running as a Windows Service) and use WCF for communication between your server and your client. You access your database from your server and let your server authenticate your users and validate that they have access to the application.
You can cheat and try to "hide" database credentials inside your client application, but that is security by obscurity and any one with some programming skills or similar can find out the credentials to the database and connect directly to the database.
I'm writing an application which will involve interaction with the database. The application will be used by users from the scale of 100 to 1000 and the database should be able to store up to 100,000 rows of data.
Previously I have used Microsoft Access but my users were required to install microsoft access database engine for my application to function as intended. I want my application to as light weight/portable as possible, so is there any better alternatives where users will not be required to install any third party components to run my application?
Look at mongoDB, it is an open source non relational database that has picked up popularity. Its is very fast too.
Depends on whether the DB will be server side or client side.
If it's server side it's up to you really, I would personally go SQL Server as I know that best, or even a mySql/phpMyAdmin combo. But if it's to reside on the client machine try SQLite (just a warning though it is exactly as the name suggests, LITE, so a lot of the more complex SQL might not be supported). SQLite may be exactly what you're looking for depending on the complexity involved in your project.
ALSO: SQLite is supported on iPhone, Blackberry and Android as well. So if you wanna go mobile, no problem.
Your application could connect to a cloud database (like SQL Azure). That will not require any third party components and it will be accessible from anywhere/any device.
Do you need a only one database for all the users or every user has it's own database? If it will be on the server side, i would prefer SQL Servers (ex. MSSQL, MySQL). But for clients side, SQLLite would do the work.
You should consider if a SaaS model is relevant, in other words if you could benefit from hosting all your users' databases on the cloud and let clients access it by remote. In your scenario I would consider a SaaS model if: (1) your users need to scale up their individual database beyond the capacity of their local machine, (2) there is a need to share data between the databases of different users - or maybe this could enable good features you don't have in your system today, or (3) users find it a drag to have to run the database on their local machine, because of the resources it uses up, uptime needed, backups, etc. If any of these are sometimes true, hosting all the databases on the cloud with some sort of multi-tenancy arrangement might be a good solution and will make your application as lightweight as possible because you don't need to include a database at all.