I recently developed a Java Application for a client with MySQL database. Now he wants to have ASP.NET website connected with the Java Application.
I'm thinking of placing the database on a local server which would support both the desktop application and the website.
What i want to know is, is it the good way to handle these kind of scenario or is there any standard method?
I also want to know what are the steps to do this?
If you're worried about having both the desktop application and the web site accessing the database, you shouldn't worry as databases are designed to have many different programs accessing them at once.
If you're worried about keeping your data in a consistent state, you should look at using a transactional MySQL database engine such as InnoDB for a start. Also, in both your application and your website you are going to have to make sure that you validate any data going in/out of the database. i.e. if someone enters garbage data from the website, make sure that this will not be saved to the database and will not crash the desktop application.
Related
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.
Right now I have a Winform app with a SQL Server back end. The DAL is comprised of Linq to SQL. One of the complexities of this app is it's need to function offline.
I have accomplished this by using Merge Replication to keep there local SQL Express instances in sync with a central SQL Server. I have some logic that detects there connection state and switches the contexts connection string appropriately.
My question is thus, will this also work with Silverlight 4? In theory, I would detect when they are offline and switch the connection appropriately. Thoughts?
EDIT
It seems this is, in fact, possible. See HERE.
What I NOW would like to understand is if I could make EF or L2S work with this instead of RecordSets like it shows.
With Silverlight (any version) the problem isn't so much connectivity to the database. In Silverlight, you don't have it. The only thing you can do is make a call back to the server that the request originated from.
Because of this, you would have to have some sort of local IIS instance running and connect to that, which would then in turn connect to the local SQL instance.
The thing is, if your SL application was loaded from your site, and then connectivity was lost, your app couldn't detect it. You would have to go to a new link to the server on the local machine and then have them switch back when they have connectivity again.
For something like this, it's probably best that you stick with the Winforms app and determine whether or not you have connectivity there. That way, you can switch which database you hit when you don't have connectivity.
What casperOne is saying is that out of browser Silverlight does not have access to a full fledged database on the client. The best that can be done is to use some sort of compact database either in the isolated storage or within one of the few accessible folders with Silverlight 4. I have personally used siaqodb.com , but you will have to keep the data synchronized manually (which can be a nightmare).
More recently I have seen someone get access to a SQL compact database. However, there could be more ways of accessing data now. It has been some time since I've looked for a client side database for Silverlight.
I'm a desktop application developer who is temporarily working in the web. I'm working with a client that wants me to build an app for use by locations all over the state; however, these locations have very shaky connectivity.
They really want a centralized web app and are suggesting I build a "lean" web app. I don't know what a "lean web app" means: small HTTP requests but lots of them? or large HTTP requests with few of them? I tend to favor chunky vs chatty.. but I've never had to worry about connectivity before.
Do I suggest a desktop app that replicates data when connectivity exists? If not, what's the best way to approach a web app when connectivity is shaky?
EDIT:
I must qualify my question with further information. Assuming the web option, they've disallowed the use of browser runtime technologies and anything that requires installation. Thus, Silverlight is out, Flash is out, Gears is out - only asp.net and javascript is available to me. Having state this, part of my question was whether to use a desktop app; I suppose that can be extended to "thicker technologies".
EDIT #2: Network is homogeneous - every node is Windows. This won't be changing.
You should get a definition of what the client means by "lean" so that you don't have confusion surrounding it. Maybe present them with several options of lean that you think they might mean. One thing I've found is it's no good at all to guess about client requirements. Just get clarification before you waste a bunch of time.
Shaky connectivity definitely favors a desktop application. Web apps are great for users that have always-on Internet connections, and that might be using a variety of different browsers and operating systems.
Your client probably has locations that are all using Windows, so a desktop application is an appropriate choice. One other advantage of web applications is that they make the deployment issue easy to deal with. Auto-update technologies like ClickOnce make the deployment and update of desktop applications almost as easy.
And not to knock Google Gears, but it's relatively new and would have to be considered more risky than a tried-and-true desktop application.
Update: and if you're limited to just javascript on the client side, you definitely do not want to make this a web app. Your application simply will not be available whenever the Internet connection is down. There are ways to save stuff locally in javascript using cookies and user stores and whatnot, but you just don't want to do this.
If connectivity is so bad, I would suggest that you write a WinForm app that downloads information, locally edits it and then uploads it. This way, if your connection goes down, all you have to do is retry until it works.
They seem to be suggesting a plain vanilla web app that doesn't use AJAX or rely on .NET postbacks or do anything that might make it break down horribly if your connection goes away for a bit. Instead, it should be designed so that you can hit Refresh until it works. In other words, they seem to want the closest thing to a WinForm app, only uglier.
You may consider using a framework like Google Gears to help provide functionality during network down time. This allows users to connect to the web page once (with a functioning connection) and then be able to use the web app from then on, even without a connection.
When the network is restored, the framework can sync changes back with the central database.
There is even a tutorial for using Google Gears with the .Net Framework.
Gears with other languages
You mention that connectivity is shaky at these locations, but that the app needs to be centralized. One thing you might consider is using multiple decentralized read database servers and a single centralized write server. Mysql makes this possible and affordable if your app is small.
Have the main database server at the datacenter/central office. Put up small web/db servers at each location, with your app installed. You can even run them off a user computer if the remote location is not too big. Make the local database servers connect to the centralized database server as replication slaves. As changes come in to the centralized database, the slave servers will pull down the data and make it available locally. When the connection is unavailable, your app data is still at least available, if not up to date. When the connection is available, the database handles replicating all relevant data down.
Now all you have to do is make your app use two separate database handles: reading data it uses the local database, writing data it uses the central database.