Nevan
> I'd prob override the ExecSQL method and do it there rather than the
> constructor
You said it was about speeding up Next method. Why are you talking about
ExecSQL ?
Alex
----- Original Message -----
From: "Neven MacEwan" <[EMAIL PROTECTED]>
To: "Multiple recipients of list delphi" <[EMAIL PROTECTED]>
Sent: Wednesday, 20 September 2000 12:17
Subject: Re: [DUG]: Wow ! Every TADOQuery.SQL changing at run-time causes
separate sp_prepare call
> Alex
>
> I'd prob override the ExecSQL method and do it there rather than the
> constructor
>
> Re ADO - A few tips
> Download the M$ Platform SDK and look at the 'dynamic properties' or the
> provider you are using
> ie for the MS SQL OLE DB Provider set
>
> ADOConnection.Properties['Multiple Connections'].Value := false;
>
> This stops the provider spawning connections on demand
>
> some others to look at are:
>
> Query.Recordset.Properties['Update Criteria'].Value := 0;
> Query.Recordset.Properties['Update Resync'].Value := 9;
>
> HTH
> Neven
>
>
>
>
>
>
> ----- Original Message -----
> From: Alex Kouznetsov <[EMAIL PROTECTED]>
> To: Multiple recipients of list delphi <[EMAIL PROTECTED]>
> Sent: Wednesday, 20 September 2000 12:44
> Subject: Re: [DUG]: Wow ! Every TADOQuery.SQL changing at run-time causes
> separate sp_prepare call
>
>
> > Nevan
> >
> > I use OLE DB. I suppose this is right is not it ?
> >
> > Regarding to using DisableControls.
> > If I had my own TControllessADOQuery component, would it be a good idea
> just
> > to put DisableControls call into its constructor ?
> >
> > Regards
> > Alex
> >
> > ----- Original Message -----
> > From: "Neven MacEwan" <[EMAIL PROTECTED]>
> > To: "Multiple recipients of list delphi" <[EMAIL PROTECTED]>
> > Sent: Wednesday, 20 September 2000 10:32
> > Subject: Re: [DUG]: Wow ! Every TADOQuery.SQL changing at run-time
causes
> > separate sp_prepare call
> >
> >
> > > Alex
> > >
> > > What Provider are you using (ODBC or OLE DB)
> > >
> > > Regards
> > >
> > > ----- Original Message -----
> > > From: Alex Kouznetsov <[EMAIL PROTECTED]>
> > > To: Multiple recipients of list delphi <[EMAIL PROTECTED]>
> > > Sent: Wednesday, 20 September 2000 12:00
> > > Subject: Re: [DUG]: Wow ! Every TADOQuery.SQL changing at run-time
> causes
> > > separate sp_prepare call
> > >
> > >
> > > > Thanks Neven, I'll try what you suggested. I was thinking of using
> extra
> > > > string (like Nello suggested).
> > > > And very interesting about Enable/disable controls.
> > > > Do you use any other tricks when working with ADOQueries not bound
to
> > any
> > > > controls ?
> > > >
> > > > Alex
> > > >
> > > > ----- Original Message -----
> > > > From: "Neven MacEwan" <[EMAIL PROTECTED]>
> > > > To: "Multiple recipients of list delphi" <[EMAIL PROTECTED]>
> > > > Sent: Wednesday, 20 September 2000 8:10
> > > > Subject: Re: [DUG]: Wow ! Every TADOQuery.SQL changing at run-time
> > causes
> > > > separate sp_prepare call
> > > >
> > > >
> > > > > Alex
> > > > >
> > > > > At the very least you should
> > > > >
> > > > > SQL.BeginUpdate
> > > > > SQL.Add ('select');
> > > > > SQL.Add ('from');
> > > > > SQL.Add ('customers');
> > > > > SQL.EndUpdate
> > > > >
> > > > > This stops the TStrings.Onchange event (which is used to compile
the
> > > SQL)
> > > > > changing on each line
> > > > >
> > > > > On an unrelated issue I was testing the performance of a
> Client/stais
> > > > > Dataset and got these results (42,000 records)
> > > > >
> > > > > To Open and download records 17 sec - To Scroll true (using next)
> 221
> > > sec!
> > > > > (on a client dataset!)
> > > > > Then I wrapped it with DisableControls/EnableControls = 3.1
> seconds -
> > > > > strange thing is it is an unbound dataset - no
> > > > > controls to disable but makes a huge difference in performance
> > > > >
> > > > > with TestDataSet do
> > > > > Try
> > > > > Open
> > > > > // 17 seconds for 42,000 records
> > > > > DisableControls
> > > > > first
> > > > > while not EOF do Next
> > > > > finally
> > > > > // 221 sec without Dis/En 3.1 with
> > > > > EnableControls
> > > > > end
> > > > >
> > > > > Regards
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: Alex Kouznetsov <[EMAIL PROTECTED]>
> > > > > To: Multiple recipients of list delphi <[EMAIL PROTECTED]>
> > > > > Sent: Tuesday, 19 September 2000 23:03
> > > > > Subject: [DUG]: Wow ! Every TADOQuery.SQL changing at run-time
> causes
> > > > > separate sp_prepare call
> > > > >
> > > > >
> > > > > > Am I crazy ? Am I doing something wrong ?
> > > > > >
> > > > > > I have just accidentally found, that whenever SQL property of
> > > TADOQuery
> > > > > > changes, there is a separate stored procedure call sent to SQL
> > server.
> > > > > >
> > > > > > It can be seen via SQL Server Profiler.
> > > > > >
> > > > > > Whenever either SQL.Add is used or SQL.Text is changed in any
> way,
> > > > there
> > > > > is
> > > > > > a call looking like "sp_prepare @p1 output etc.."
> > > > > >
> > > > > > If I do
> > > > > >
> > > > > > SQL.Add ('select');
> > > > > > SQL.Add ('from');
> > > > > > SQL.Add ('customers');
> > > > > >
> > > > > > then there will be 3 calls to sp_prepare !!!
> > > > > >
> > > > > > I generate long sql statements in loops and get tonns of this
> sent
> > to
> > > > the
> > > > > > server.
> > > > > >
> > > > > > I found that these calls do not occur if ParamCheck property of
> > > ADOQuery
> > > > > is
> > > > > > set to FALSE ! But then ':' style parameters do not get
recognized
> > by
> > > > ADO
> > > > > > and they all have to be somehow manually created.
> > > > > >
> > > > > > Does anyone have any suggestions,comments,ideas on this ?
> > > > > >
> > > > > > Regards
> > > > > > Alex
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> --------------------------------------------------------------------------
> > > > > -
> > > > > > New Zealand Delphi Users group - Delphi List -
> > > [EMAIL PROTECTED]
> > > > > > Website: http://www.delphi.org.nz
> > > > > > To UnSub, send email to: [EMAIL PROTECTED]
> > > > > > with body of "unsubscribe delphi"
> > > > > >
> > > > >
> > > >
> > >
> >
>
> --------------------------------------------------------------------------
> > > > -
> > > > > New Zealand Delphi Users group - Delphi List -
> > [EMAIL PROTECTED]
> > > > > Website: http://www.delphi.org.nz
> > > > > To UnSub, send email to: [EMAIL PROTECTED]
> > > > > with body of "unsubscribe delphi"
> > > > >
> > > >
> > >
> >
>
> --------------------------------------------------------------------------
> > > -
> > > > New Zealand Delphi Users group - Delphi List -
> [EMAIL PROTECTED]
> > > > Website: http://www.delphi.org.nz
> > > > To UnSub, send email to: [EMAIL PROTECTED]
> > > > with body of "unsubscribe delphi"
> > > >
> > >
> >
>
> --------------------------------------------------------------------------
> > -
> > > New Zealand Delphi Users group - Delphi List -
[EMAIL PROTECTED]
> > > Website: http://www.delphi.org.nz
> > > To UnSub, send email to: [EMAIL PROTECTED]
> > > with body of "unsubscribe delphi"
> > >
> >
>
> --------------------------------------------------------------------------
> -
> > New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
> > Website: http://www.delphi.org.nz
> > To UnSub, send email to: [EMAIL PROTECTED]
> > with body of "unsubscribe delphi"
> >
>
> --------------------------------------------------------------------------
-
> New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
> To UnSub, send email to: [EMAIL PROTECTED]
> with body of "unsubscribe delphi"
>
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"
