State or stateless The Browser and the desktop application work in very different ways and this has implications for both the user experience and the cost of development.

As a horrible oversimplification, the more that an application needs to know about things not on the current screen the more likely it is that it should be a desktop application.
The Browser - Computing Model
Stateless With a Browser based application you basically have a program that starts and ends with the current page. The original idea was that the current page has no need and no way of knowing what has been going on in other pages.

In practice this is an unusable situation for most web sites and there have been some attempts to make this model work better, such as session variables. Browser based sites as best suited to sites that are online brochures or do simple step by step processes like a simple shopping cart.

I run a business application Simple Service Centre that is browser based, and the development was much harder and longer than it would have been as a desktop application.

The Desktop - Computing Model
Wall Unlike a Browser based application, a desktop application starts, retains as much information and resource as is requires until it wishes to release them.

In the stated model, applications can be developed much faster and cheaper and with a better user interface, but tend to be tied into the office. However remote desktops do allow this table of application to be run via and internet connection.

Processing and editing the message on the right is something that should clearly be a desktop application.
Web Or Desktop
80% Working is good enough for the web!
Error message The web world has introduced the concept that a web site/program that works about 80% of the time is good enough.

This was not an objective, it is a combination of people chasing fancy special effects, not understanding what they are doing, and sometimes the web site owner simply not being prepared to pay for a proper job to be done. More details on this theme.

Interaction Between Controls
Error message Many people will have tried the car insurance comparison sites, where a user selects the car manufacturer, make and model. This is a very large list and it is not really a good idea to load everything into the browser/desktop application.

Both application types would show a manufacturer selection list, when something is selected, the make list is populated and then the model list. In a browser app, this can be done by completely refreshing the whole page, which looks naff to the user, or by using an Ajax wrapper around the make and model controls.

The problem is that Ajax is unreliable in the Real World, so do you go for a good looking web site that may not work or a bad looking site that will.

The desktop application does not have this problem because it is more tightly bound together.

In practice the code required to get the data from the database will be same, but the code to update controls in the desktop application will usually be a lot quicker to write and test.

Development Environments
Web - ASP/SQL Server/Windows or PHP/MySQL/Linux!
Wall Although there are plenty of other options, it is most likely that if you ask someone to build you a web site you will be offered one of these two options; ASP/SQL Server/Windows or PHP/MySQL/Linux.

It is possible to build a C# (ASP) web site on Linux/Mono/MySQL or PHP/MySQL on Windows, but if you do, you are going to raise a lot of eyebrows and find support difficult.

My view is closer that your web site is to an application, the more likely it is that ASP.Net/SQL Server is the way to go. The primary reason is that the development environment is better meaning that the site will be developed more quickly and hopefully will be more reliable.

Things like being able to single step through stored procedures without changing the debugger are not relevant to a basic web site, so either route makes sense.

Desktop - Microsoft VB.Net or C# are the most likely choices
Wall There are plenty of options for desktop development, such as Java, MS Access using either the Access or SQL server databases, tools from Oracle and IBM etc.

But most people who are looking at this site will probably be best served by the Microsoft route. People to develop and support it are abundant, Microsoft does have a pretty good record on supporting older technologies and the cost has come down quite a lot recently.

In many respects VB and C# are very similar, but I tend to take the view that if you use C# you will be more likely to get a better programmer. I am not saying that all VB programmers are bad, but that bad programmers tend to learn VB not C#.
Side Notes
padding picture
This is an EDI message, if you buy your car insurance from a broker it is likely that a message like this will be generated by the broker's computer system and sent to the insurance company.

The insurance company will decode and validate this message and there is a very real (1%-5% chance) of there being an error.

As you can imagine processing this requires a lot of computing, for example the VHC segment says this is a policy for Insured And Spouse, this means that there must be two DRI segments, one for each driver. The whole message has lots of relationships like this, there may be 4 DRI segments on another policy, the number is defined by the DTR.

Trying to process all this information and display it all in one page for a operator to modify is clearly impractical, A desktop application that I created to fix this type of message had a form for each segment type and stored the whole message in memory.