It has to be prepared once at least. The difference is that once prepared it
will remain so in order that subsequent executions(posts) will not have the
overhead of preparing the statement to handle the update.

Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

-- We may not have it all together --
-- But together we have it all --

----- Original Message -----
From: <ibo@...>
To: <IBObjects@yahoogroups.com>
Sent: Friday, February 21, 2003 5:15 AM
Subject: Re: [IBO] PreparedEdits does not work as expected?


> Svein,
>
> Great! Now we come to the point: why "But this ad-hoc DSQL still has
> to be prepared before being executed." as you said? It really matters
> because each prepare generate 40KB traffic from server to client,
> this is expensive for remote client. If only it doesn't prepare and
> just execute. I think that is technically possible.
>
> I am always finding ways to optimize for remote clients.
>
> Rgds,
> Michael
>
>
>
> --- In IBObjects@yahoogroups.com, Svein Erling Tysvaer
> <svein.erling.tysvaer@k...> wrote:
> > At 08:38 21.02.2003 +0000, you wrote:
> > >Perhaps you are right, but I would think "a DSQL statement for just
> > >the updated columns should be constructed and immediately executed"
> > >means skipping the prepare stage. For example, a table with many
> > >large fields, it will save traffic by only sending the changes
> > >instead of all data fields. If you use one prepared update
> statement,
> > >you will send all data fields.
> >
> > Well, I think this is what PreparedEdits is all about. If
> PreparedEdits is
> > true, then as you say all data are sent for each update. If it is
> false,
> > then a new DSQL statement is constructed every time with only the
> changed
> > fields (and the PK) sent to the server. But this ad-hoc DSQL still
> has to
> > be prepared before being executed.
> >
> > Set