Try using a replicator. That's how I solved a similar performance
problem, and I'm very satisfied. If you replicate every minute or so,
the asynchronous nature of it is hardly felt by the user at all, and
every one, whether locally or on the remote sites, has exactly the same
speed. It's a bit of work setting it up, but well worth it!
Also, it avoids all problems related to the connection getting cut : if
ever that happens, it just doesn't matter!

My customer has an ADSL connection, not a VPN. The connection speed was
(theoretically) 128 both ways (because there are two remote sites). When
the lines were clear, things were ok (though not very enjoyable), but
when all three machines on the two remote sites were using the
application intensively, it became almost unusable. Now, everyone's at
the same speed!

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).

Hope this helps,
Jonathan Neve.

sllimr7139 wrote:

>Hi Ivan,
>
>
>
>>Are you aware that due to RLE compression algorithm used by Firebird
>>for storing rows on disk even empty string stored into
>>VARCHAR(32000) field will occupy 500 bytes ? (and thus only few
>>rows will fit onto database page which can drastically reduce
>>preformance)
>>
>>Have you considered storing data in blob and convert them to
>>varchar using UDF for reading ?
>>
>>
>
>Diskspace and CPU time are not a concern with this application. Pure
>transfer speed over the VPN is. The data was originally stored in
>blobs, I've moved away from them specifically to address speed issues
>across a VPN connection.
>
>If I had designed the database originally and had full control over
>the application design then of course I would use blobs. Since I
>don't have full control and I've only been brought in at the end of
>the applications development, I'm doing what I can to make it run at a
>respectable speed.
>
>Ryan.
>
>

[Non-text portions of this message have been removed]