>
> > I have a customer with have an DB that supports 20 clients.
> > 15 of those clients connects through an ADSL line to a terminal
> > server in the head office.
> > Here they run our program which connects to a DB on another

server.

>
> So, if I understand correctly 5 clients are on the LAN and 15

clients

> are off-site running via Terminal Server.

Yes

>
> > Then our customer moved the head office location.
> > When this happened the Internetline at the head office of course
> > changed.
> > They got a ZyXEL Router instead of a Cisco i.e.
>
> > Now the clients keep falling of every once in a while.
>
> Are those that are on the LAN falling also?

No. They stay connected hence the problem must be the line, correct ?

>
> > First I assummed, that I had created to many index' on to many

tables.

> > So laft week i drop a lot of index' on the DB.
> > Now every table contains no more than 8 index'.
> > Most of the tables only contains 4 index'
>
> As some mentioned, indices shouldn't make any difference, unless

there

> was a big change in the data and data structure at the same time of
> the move.
>
> > We have been pinging the clients router at the new location, and
> > every once in a while the respons time from the router is not
> > available.
>
> Just reaffirming what someone said, it could be either the line or

the

> router. Also, what are the settings of the Terminal Server clients?
> Is compression and/or encryption turned on?

Encryption and compression on (as it was before).

>
> > Now my theori goes on this:
>
> > 1 clients is about to do an update, and therefor starts an
> > transaction.
> > The connection to the terminal server goes down.
> > After a few seconds the session is terminated, by both server and
> > client.
> > And after another few seconds the firebird DB realizes that the
> > connecton has been lost and rollbacks whatever transactions are
> > active (Does anyone know how long time there will go) ?
>
> The Terminal Server session log-off time can be stretched or
> eliminated, so the application can still run until the user connect

to

> the session again. Those settings are found on the server.
>
> > So I think that the poor quality of the internet line causes this.
> > Is that likely to be the case ?
>
> Check how Terminal Server is configured. If compression is turned
> off, try turning it on. Also, the time-out of the sessions can be
> adjusted. This would mean that if the session is dropped accidently
> or even intentionally, the user will have a certain amount of time

to

> connect again and resume the session.

When a client lose a connection it is at this set to reset the client
side.
We are talking about setting it up, so the dekstop will remain until
disconnection.

But there are other things we then have to take into mind, but these
things can be altered.

>
> > Or Could it be anything else ?
>
> Not that I can think of.
>
> One thing to remember, Terminal Server sessions are running on the
> server, so your application is running on the server as well, not on
> the client machine.

This I know.


Thank you anyway.

Michael

>
> Have a nice day.
>
> Daniel Rail
> Senior System Engineer
> ACCRA Group Inc. (www.accra.ca)
> ACCRA Med Software Inc. (www.accramed.ca)