Hi Jonathan,

> Try using a replicator. That's how I solved a similar performance

<snip>

> worth it!

I'm not sure the answer to this customers problem is a replicator.
The nature of the database and application are such that the customer
just wants to allow his service/sales reps to establish a vpn
connection to the office and its database over their clients internet
connection. Not to have multiple copies of the database floating
around. If the connections were a permanent thing I think that the
replication would be a better solution. Unfortunatly the connection
is on an as needed basis thus forcing the application to wait an
indetermined amount of time on every connection to wait for the
replication process to complete the updates. Not a good solution.

> Also, it avoids all problems related to the connection getting cut
> : if ever that happens, it just doesn't matter!

Agreed! But once again, that's only for an established *permanent*
connection. Maybe something like a breifcase model would be a better
answer to this problem.

> Also, you could try using Zebedee (if you don't already) to
> compress the data going through the wire on the fly. Perhaps this
> would help (although I've never tried it myself; once the
> replicator was working, I no longer had any real need for it).

The existing application model is not condusive to running over the
VPN connection. The problem is not the size of the blobs but the
entire connection and data retrieval process. The orginal desiger and
coder of the application and database has learned a number of things
about his design since I've started consulting on the project. Some
of those things have to do with efficiency, other have to do with how
an RDBMS works. His company is moving away from a type of flat file
database system where the programming langauage (a form of basic)
controled the storage and retrieval of all the records. Oh BTW did I
mention the original application (the one written in basic) was a
(ANSI?) terminal client application?

Thanks for all the info.

Ryan.