What is better? 2

[Gigatech]

I want to run my application on a network. What is better?:

1) Put the exe file in the Server and create a shortcut in each client machine.
Problem: too slow?

2) Put the exe file in each machine and configure the path of the Database for each one.
Problem: If I want to upgrate the program I need to update each machine?

Thanks

 

[TonHu]

I'l try to give some downsides for both situations:
1)
a) Network traffic can be high (as stated)
b) ODBC Database connections may have to be setup per client
c) If clients are on a WAN connection, startup will be slow
d) Upgrading the app (or modules) requires all users to exit

2)
a) Upgrade has to be distributed (as stated)
b) Setup can be less easy
c) Clients all have to be up-to-date to accomodate (major) database changes

And I'll also try to come up with some advantages for both:
1)
a) Single point of maintainance (as stated)

2)
a) Network traffic can be lower (as stated)
b) Startup time should be quicker for clients

Upgrading the client-side of the app (situation 2) could be quite easy, as an .INI file can hold the latest available client-version, and a simple copy can do the upgrade.

As you can see, it's quite hard to make a proper decision on what's 'right' or 'better'. It all depends on the situation.
In both situations I'd advise some sort of client/server database (ODBC?), as pumping all data across the network to have the app (not) find a name in a table, does generate a lot of network traffic, where a SQL query would only transport the query, and the actual result (no records found ;-) ) over the network.

HTH
TonHu

 

[Nordlund]

Hi.
I prefer using alternate 2.

Distribute the application to every client.
We have done this since 1989, and we have no complaints at all with this solution.
(Total client count: more than 6000)

We store the application(s) on the database, and when a new version exist on the database, the client will do a "self upgrade", and "woilaaaa", the client have thw new version automatically.

The downside with this solultion would be the datatransfer when we deliver a new application version.

But on the other hand, the application is more flexible, and the user doesn't need to have access to the same network share. Only Port 1433 (Default MSSQL) or port 5000 (Default Sybase).

//Nordlund

 

[svanels]

Alternative 2, less headache,

Steven van Els
SAvanEls@cq-link.sr

 

[whosrdaddy]

or you can go n-tier

Server-DB-RDS(serverApp)---LAN-ClientApp

--------------------------------------
What You See Is What You Get

 

[Griffyn]

There's no real difference between the two in terms of network traffic:

In option 1, each client runs the application, which is transferred across the network (minor bit of traffic) to their computer into RAM and executed. At this point, everything that the application does (assuming no DLLs) will be exactly the same as option 2.

Definitely go option 1, if your application is a simple set up like this. Maintenance and settings are all managed from a single location.

Depending on what your application does with the database, it may be of no benefit to redesign it into a client/server architecture.

 

[Nordlund]

Hi Griffyn.
Because I voted for Alternative 2, I have to defend it ...

When ugrading using alternative 1, you always have to kill all access to the specified file first, before you can delete it and replace it witha new version.

//Nordlund

 

[LucieLastic]

A few of my apps run over Citrix which is (I feel) easier on all fronts ...

 

[Nordlund]

Yes, that might be correct.
But then we have to include 3rd pary applications.

There is one problem with Citrix, depending how you want to publish the application....

What if you want to upgrade a used application on the Citrix server? Can you do this without telling yous users to log out from the application, before you can delete It.

(Some of our customer run Citrix, and they have do log out, not from Citrix, but from the Application going to be updated)

//Nordlund

 

[Griffyn]

Hi Nordland,

True - you have to get everyone out of the application before upgrading it, but you also have a similar problem when the application is distributed. With Alternative 2, you still have to get each individual out of the application before you can transfer an update to them. Plus, having multiple copies of the application out there makes it easy for multiple versions to coexist, which may interfere with the shared database version, and other version conflict issues.

I use Citrix at the office and it's simple to issue a global 'kill' command to get everyone out the application immediately. This obviously may not be suitable depending on the type of application.

 

[Nordlund]

Hi.
Vi can discuss this in eternity

With Alternative 2, you still have to get each individual out of the application before you can transfer an update to them. Plus, having multiple copies of the application out there makes it easy for multiple versions to coexist

Naaaa, it depends how you are proceeding with the upgrade...


This solution are of course done automatically without "hands on" from the client.

1. Start "File.exe"
2. The client verifies the version of "File.exe" when logging in to database.
3. If a different version exist, then copy "File.exe" to a backup directory, and start the backup file with an argument: "File.exe upgrade"
4. Then, when another copy of "File.exe" is started, you are allowed to delete the original "File.exe".
5. Download the file from database, and name it "File.exe" (In the original directory)
6. Start the original "File.exe" and voilaaa!, the new version are delivered...
7. Clean up backup directory.


If you are using this way, every user have the newest version of the file, and no kickouts are required....

//Nordlund

 

[lloydie2]

Or if possible a web app. No need to distribute/upgrade client app

 

[Nordlund]

Good point there...

//Nordlund