--- In firebird-support@yahoogroups.com, "matf_de" <matze@...> wrote:

>
> Well, the application has to connect to Fb. No way out !

Clearly you have not designed your application to run over a slow
speed and high latency link (even fast broadband internet has both of
these properties). If you intend to deliver an application over the
internet, then it needs to be designed from the ground up to not
expect instantaneous responses to queries, and most client server
applications are not written in such a way.

Normally for client-server:

1. User Opens Form,
2. Application establishes connection, starts transaction and issues a
query.
3. Application waits for a response
4. Database returns data to client
5. Application then does whatever it was going to do and then possibly
sends data back to the client.

Items 2 - 4 involves a lot of chatter, even more if BLOBs are
involved. On a LAN, you may not notice the chatter because you expect
to be able to send/receive 10MB/s in under 1ms. On the internet
however, you are unlikely to have that sort of throughput (we do at
out data centre but that is a considerable cost). The response time to
our data centre from our ASDL connection is still around 20ms (when
nothing else is happenning, it blows out if someone downloads something).

There are many methods of countering this slowness, and most of them
are off topic for this list, the usual approach is to replicate the
data needed so that the clients are not waiting as often, or to use
some sort of application server or n tier model.

None of these are particularly attractive if you have already designed
your application. In this case, I would recommend a Terminal Services
based approach. This is a best of both worlds approach. As far as your
application performance goes, it is running on the same physical LAN
as the database server (and you can make it a gigabit LAN for even
better performance). The only things constantly travelling between
client and server are screenshots and keystrokes. Performance is
acceptable even on a 56K modem, although broadband is preferrable.

Using this approach means that support is easier through shadowing,
that you know they haven't loaded up their 256MB of RAM with 1000
background processes, that you know that security patches are applied,
makes upgrading a breeze, means that your application will now work on
Macs and *nix machines via their RDP clients, don't need to worry
about some win98 box not having some msvc... dll, gives less grief if
using events as you no longer need to negotiate with their site techos
to open ports, encryption and compression is taken care of for you by
the protocol (the list goes on).

Adam