| Subject | RE: [ib-support] Re: excessive network traffic [LONG] |
|---|---|
| Author | Leyne, Sean |
| Post date | 2001-01-29T18:44:49Z |
Art,
My comment about single statement commands, was a really two-fold
comment.
I was referring to queries which are only executed once and therefore
the 'cost' or preparing the query and retrieving the metadata can't be
re-used.
I was also referring to queries which return only a few rows, in which
case, the overhead of the query is very high compared to the processing
time.
In your case, your queries take a double hit - they are only executed
once and return very few rows.
With respect to installing the new SP. I was thinking that you could
make the application update the database itself, instead of depending on
your users. Allow me to explain.
1) You modify your EXE to run a new SP to return the "version"
information you need.
2) When the application starts up it calls the new SP.
3) If you get an exception calling the SP, you can check if the
procedure exists.
4) If the procedure doesn't exist, you could then have the application
create the procedure. Once created, you run the SP to return the
version information.
This sequence of events (2, 3 and 4) would only the first time the new
application started, thereafter, the application would use the new SP.
Sean
-----Original Message-----
From: Art Metz [mailto:ametz@...]
Sent: Monday, January 29, 2001 1:16 PM
To: 'ib-support@yahoogroups.com'
Subject: RE: [ib-support] Re: excessive network traffic [LONG]
Sean,
what exactly do you mean? A single SELECT statement? Each row fetched
by a
SELECT statement? Something else?
replace all my queries with SPs. I see your point. My problem with
this
suggestion is that I'll have to provide a script to update each database
with the new SP. Recall that this is a commercial app, so I don't
control
the fielded databases; that backwards compatibility is required; and
that,
in general, my users are morons.
Art Metz
AMetz@...
ib-support-unsubscribe@egroups.com
My comment about single statement commands, was a really two-fold
comment.
I was referring to queries which are only executed once and therefore
the 'cost' or preparing the query and retrieving the metadata can't be
re-used.
I was also referring to queries which return only a few rows, in which
case, the overhead of the query is very high compared to the processing
time.
In your case, your queries take a double hit - they are only executed
once and return very few rows.
With respect to installing the new SP. I was thinking that you could
make the application update the database itself, instead of depending on
your users. Allow me to explain.
1) You modify your EXE to run a new SP to return the "version"
information you need.
2) When the application starts up it calls the new SP.
3) If you get an exception calling the SP, you can check if the
procedure exists.
4) If the procedure doesn't exist, you could then have the application
create the procedure. Once created, you run the SP to return the
version information.
This sequence of events (2, 3 and 4) would only the first time the new
application started, thereafter, the application would use the new SP.
Sean
-----Original Message-----
From: Art Metz [mailto:ametz@...]
Sent: Monday, January 29, 2001 1:16 PM
To: 'ib-support@yahoogroups.com'
Subject: RE: [ib-support] Re: excessive network traffic [LONG]
Sean,
> I had suspected that BDE/IBO/IBX each would have the sameOy, I'm sorry to hear this. When you say "single-statement" operations,
> general amount of overhead when performing single statement
> operations. We did some benchmarks quite some ago which
> bore out this point.
what exactly do you mean? A single SELECT statement? Each row fetched
by a
SELECT statement? Something else?
> [My] initial suggestion to replace the 4 separateAhh, I see now. I misinterpreted your initial post to suggest that I
> queries/statements which he is currently performing, with a single
> SP call did not meet with a warm reception (even though he would
> eliminate most of the network activity and increase overall
> performance).
replace all my queries with SPs. I see your point. My problem with
this
suggestion is that I'll have to provide a script to update each database
with the new SP. Recall that this is a commercial app, so I don't
control
the fielded databases; that backwards compatibility is required; and
that,
in general, my users are morons.
Art Metz
AMetz@...
> -----Original Message-----To unsubscribe from this group, send an email to:
> From: Leyne, Sean [mailto:InterbaseSupport@...]
> Sent: Monday, January 29, 2001 9:55 AM
> To: 'ib-support@yahoogroups.com'
> Subject: RE: [ib-support] Re: excessive network traffic [LONG]
>
>
> Nando,
>
> I was simply trying to tell Art to use the SQLMonitor so that he could
> see the traffic and appreciate what its doing. What looks to be a
> simple statement/query can generate quite a bit of network activity.
>
>
> As you point out, the true benefit of IBO and IBX is in extending the
> basic functionality provided by the BDE.
>
>
>
> Sean
>
> -----Original Message-----
> From: Nando Dessena [mailto:nandod@...]
> Sent: Monday, January 29, 2001 12:07 PM
> To: ib-support@yahoogroups.com
> Subject: Re: [ib-support] Re: excessive network traffic [LONG]
>
> Sean,
>
> > Try using SQLMonitor to see the traffic generate by the BDE - you'll
> be
> > impressed (that's one word <g>) by the traffic generated.
>
> a well-behaved (that is, no TTables, no live TQueries, no Locates) BDE
> application does not generate *much* more traffic than a IBO/IBX one.
> The bad side of the BDE is the terrible lack of functionality if you
> follow those guidelines, whereas other tools like IBO give you
> efficiency AND functionality.
> --
> ____
> _/\/ando
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-~>
> eGroups is now Yahoo! Groups
> Click here for more details
> http://click.egroups.com/1/11231/0/_/_/_/980791426/
> --------------------------------------------------------------
> -------_->
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
ib-support-unsubscribe@egroups.com