I’ve built an online scheduling system for a local company so that they can have a calendar with the scheduled jobs for the day and so that the customers can check on the progress of the work being done for them. Allowing the customer to check for themselves would cut their phone call volume down to about 30% of what it is now leaving more time to complete jobs.
Everything is fine but I’m concerned about instances when either the server has issues or the business’ internet is down.
I was considering making it a desktop application but then it wouldn’t have the online abilities of allowing the customers to check on the job’s progress.
So, basically, as it stands now, if there is problems with the internet connection, either at the business or at the host, the business loses their daily scheduler and if I make it a desktop app the customer has to call to check on the progress. Unless I can make the local database copy any transaction made on the desktop app to the database on the server.
How would I go about doing something like that? Would this be a good reason to use a web service (something I’ve never done)?
The hosting and connectivity has never failed. All this is just in case it does. Contingency planning. If one or the other fails the entire shop schedule goes kaput which would make the current dry-erase board look pretty good.
Yeah, that’s covered in the thread title: “Using a single database (or copied databases) for a hosted site and a desktop app”. Managing 2 separate databases isn’t the ultimate solution though.
I think you are approaching this from the wrong angle.
If i were you i would create 2 apps - 1 web and 1 windows.
the web app to be created in asp.net, hosted with a normal hosting provider.
the web app will need to connect and use its own sql db and will serve as the public interface for the system.
the windows app will also connect to its own sql db located on the offices internal server, the office staff can use this app to update all of the schedules.
You then configure the 2 db’s to synchronise, either by a schedule or everytime a new schedule is added / updated.
I suppose I should explain that the site is ASP.NET using MSSQL.
I’m not very savvy to WPF (XAML is foreign to me) so I may just run an internal calendar/scheduling system for the company using ASP.NET without all the extra web frontend that the public will see on their web site. However, changes they make to their schedule will have to be available on the net.
I suppose the ultimate solution would be to host it locally at the shop. Barring that could I connect to the web host using an ASP.NET Web Service? That way making changes to the local database would be reflected on the web host.
Yeah, XAML does look alien, I should know, I’m learning it. Anyways, on the subject. Have you ever thought of using WCF? You could create the desktop app that alters data on the remote host. Just an option.
Ah, this is why I’m asking. I’m not familiar with WCF. Tell me more. Does it require something running on the host or does the local desktop app communicate directly with the remote host?
I have a feeling I’m stepping way out of my comfort zone on this one. I most likely won’t have time to learn XAML, WCF, WPF or anything else until somewhere around November.
Host and clients communicate with each other by agreeing on the ABC’s, a friendly mnemonic for remembering the core building blocks of a WCF application ‘address,binding, and contract’.
Alright, here are the three ‘areas’ to send a service:
Address: It describes the location of the service. So, for example, in code, that you represent this with a typical “URI” type. However, you typically store it in a .config file.
Binding: WCF. It basically consists of network protocols, encoding mechanisms, and the transport layer.
Contract: Provides the description of each method exposed from the WCF service.
You will want to research: HTTP-Based Bindings and WCF Addresses.
I most likely won’t have time to learn XAML, WCF, WPF or anything else until somewhere around November.