At 01:55 AM 29-11-02 +0000, you wrote:

>2. The plan for the "slow" query running on Remote is here:
>/*---
>PREPARE STATEMENT
>TR_HANDLE = 4150092
>STMT_HANDLE = 4149900
>
>SELECT ID, NAME FROM BRAND
>
>PLAN (BRAND NATURAL)
>
>FIELDS = [ Version 1 SQLd 2 SQLn 30
> BRAND.ID = <NIL>
> BRAND.NAME = <NIL> ]
>
>SECONDS = 5.875
>----*/
>
>3. The plan for the "slow" query running on Local network is here:
>/*---
>PREPARE STATEMENT
>TR_HANDLE = 4150760
>STMT_HANDLE = 4150568
>
>SELECT ID, NAME from brand;
>
>PLAN (BRAND NATURAL)
>
>FIELDS = [ Version 1 SQLd 2 SQLn 30
> BRAND.ID = <NIL>
> BRAND.NAME = <NIL> ]
>
>SECONDS = 0.040
>----*/
>
>
>You can see the dramatic delay in remote situation.
>The returned result set is very simple:
> ID NAME
>============ ====================
> 1 AMD
> 2 INTEL
> 3 MOTOROLA
> 4 FAIRCHILD
> 6 SANYO
>
>I guess the prepare stage involve a lot of traffic, am I right?

No. But if you are forcing a prepare to occur every time the same query is
run, you are adding that overhead every time. Refer back to my comments on
this subject about 3 messages agol

>Is there anything I can do to eliminate it?

No. The prepare is an essential part of the conversation between the
client and the server. But you should try to architect your queries so
that you don't have to prepare unless it is necessary.

Your monitor figures are very revealing. They show that it is not the
client nor the server which is causing the slowness, but your network.

These kind of figures are what I observe when querying from a client across
the web.

So just how remote is "remote"?

What is your remote protocol?

What else is your physical network doing?

Helen