Re: What would you use?

"Paul Hughes" <hughes.pa@xxxxxxxxx> wrote in message news:480dac0a$1@xxxxxxxxxxxxxxxxxxxxxxxxx

Biggest customer has around 50 branch offices nationwide all linked to a central HQ via reasonably quick broadband with between 2 and 20 users at each branch and probably 30 or so users at HQ.

Are they all accessing the same Paradox tables at HQ, or each office has its own database?

Biggest customer has an existing MS SQL server and some IT expertise.

Smaller customers (and new ones) want free or low cost DB licensing.

If they want to make use of their existing MS SQL Server (reasonably so) then, as Alessandro suggested, you can use SQL Express. The database is still full MS SQL Server, so should an office outgrow Express, there's no problem upgrading them.

Biggest customer feels they should have web or browser based access to the system and feel that all the data should be on their central HQ servers. (I think this is probably because it's the latest 'trend', not necessarily because it's better for them)

I don't blame them for wanting all data centralized (if it currently isn't). That puts security and backup concerns in one place, and also allows easier reporting across offices.

As the application is very data intensive, can any web/browser based replacement achieve the full functionality, speed and user experience that the current app offers.

It's not the browser interface, it is the difference between Paradox access, especially if on a local network, vs accessing a server database, especially if across the internet. You need to take a completely different stance when designing for the latter - always with the goal of fetching the *minimum possible* data from the server at any time - show the user only what they explicirly ask for or need rather than the typical desktop database mode of display everything so they can waste the day scrolling through everything they *don't* need to see.

As far as a browser interface, they are gradually getting better, but in general, unless I see a particular advantage, I still recommend native GUI applications. They can easily be run across the internet a couple of ways - Remote Desktop, or a VPN. If they have a legitimate desire to run these on portable devices and such, then web browser access makes more sense.

Should there be a regular (desktop installed app) for the serious users and a lesser featured web/browser based alternative for use as the situation demands.

I would do one or the other. If your application can *reasonably* be done as a browser app (or needs to be as above), then there is no reason to *also* maintain a desktop GUI.

--
Wayne Niddery - TeamB (www.teamb.com)
Winwright, Inc. (www.winwright.ca)

.

Relevant Pages

  • Re: Upgrade Access backend to SQL database
    ... end to SQL tables rather than the current Access table structure. ... If the database is well designed in Access and then upgraded to SQL Server ... It's a five-star book at Amazon.com for a very good reason. ...
    (microsoft.public.access.modulesdaovba)
  • Re: Case Senstivity on SQL Server
    ... good reason, but it doesn't sound like there's any reason you need to ... break things if you change the collation of a database. ... The collation of the server instance is set when the instance is ... You can change database collations with ALTER DATABASE, ...
    (microsoft.public.sqlserver.mseq)
  • Re: Detecting number ranges
    ... database 1 is on server 3 ... For that same reason, the input's initially unsorted - it's *mostly* ... jay at jay dot fm | cry or shout or hit. ...
    (comp.lang.ruby)
  • Re: Error Message
    ... Ignore the reason (upgrade from WMSDE to SQL Server ... > Unable to connect to database. ...
    (microsoft.public.sharepoint.windowsservices)
  • Create SharePoint Portal failed.
    ... One mentioned ensuring that SQL Server uses a case ... 13:55:40 Service database server is 'USDC-JOHRIV'. ... Update dbo.propertylist set DisplayName = N'Last name' ...
    (microsoft.public.sharepoint.portalserver)