Query parallelism/ACCESS and DUAL PROCESSORS?

We have a large operation - SQL server with lots of users attaching via VB programs. Most operations to the database occur within stored procedures.
The SQL server is also used by an ACCESS front end for another application.
The ACCESS queries started getting this error:
Server: Msg 8650, Level 13, State 127, Line 1
Intra-query parallelism caused your server command (process ID #79) to deadlock. Rerun the query without intra-query parallelism by using the query hint option (maxdop 1).
The ACCESS developer found some KB articles indicating that turning off the DUAL PROCESSOR would fix the problem.
We have concerns about how the rest of the server usage will react to turning off the DUAL PROCESSOR option.
Anyone have experience with this type of problem?
Usually the work-around states that you can disable the use of multiple
processors at the server level OR you can disable parallelism for the
specific query causing the problem. Assuming that you can identify the
specific queries and can modify them, then it is far better to change the
queries. Otherwise you lose the benefit of multiple processors which can be
very significant!
"Steve Z" <SteveZ@.discussions.microsoft.com> wrote in message
news:08A84C96-7E31-4937-A419-4EBB06E10082@.microsoft.com...
> We have a large operation - SQL server with lots of users attaching via VB
programs. Most operations to the database occur within stored procedures.
> The SQL server is also used by an ACCESS front end for another
application.
> The ACCESS queries started getting this error:
> Server: Msg 8650, Level 13, State 127, Line 1
> Intra-query parallelism caused your server command (process ID #79) to
deadlock. Rerun the query without intra-query parallelism by using the query
hint option (maxdop 1).
>
> The ACCESS developer found some KB articles indicating that turning off
the DUAL PROCESSOR would fix the problem.
> We have concerns about how the rest of the server usage will react to
turning off the DUAL PROCESSOR option.
> Anyone have experience with this type of problem?
|||get rid of the access clients.
Greg Jackson
PDX, Oregon

Query parallelism/ACCESS and DUAL PROCESSORS?

We have a large operation - SQL server with lots of users attaching via VB p
rograms. Most operations to the database occur within stored procedures.
The SQL server is also used by an ACCESS front end for another application.
The ACCESS queries started getting this error:
Server: Msg 8650, Level 13, State 127, Line 1
Intra-query parallelism caused your server command (process ID #79) to deadl
ock. Rerun the query without intra-query parallelism by using the query hint
option (maxdop 1).
The ACCESS developer found some KB articles indicating that turning off the
DUAL PROCESSOR would fix the problem.
We have concerns about how the rest of the server usage will react to turnin
g off the DUAL PROCESSOR option.
Anyone have experience with this type of problem?Usually the work-around states that you can disable the use of multiple
processors at the server level OR you can disable parallelism for the
specific query causing the problem. Assuming that you can identify the
specific queries and can modify them, then it is far better to change the
queries. Otherwise you lose the benefit of multiple processors which can be
very significant!
"Steve Z" <SteveZ@.discussions.microsoft.com> wrote in message
news:08A84C96-7E31-4937-A419-4EBB06E10082@.microsoft.com...
> We have a large operation - SQL server with lots of users attaching via VB
programs. Most operations to the database occur within stored procedures.
> The SQL server is also used by an ACCESS front end for another
application.
> The ACCESS queries started getting this error:
> Server: Msg 8650, Level 13, State 127, Line 1
> Intra-query parallelism caused your server command (process ID #79) to
deadlock. Rerun the query without intra-query parallelism by using the query
hint option (maxdop 1).
>
> The ACCESS developer found some KB articles indicating that turning off
the DUAL PROCESSOR would fix the problem.
> We have concerns about how the rest of the server usage will react to
turning off the DUAL PROCESSOR option.
> Anyone have experience with this type of problem?|||get rid of the access clients.
Greg Jackson
PDX, Oregon

Query Parallelism Configuration

I am working with a SQL Server 7 (SP4) box with 8 processors. When I
bring up Enterprise Manager and go to the Processor tab under server
properties, I can see the configuration for the parallel execution of
queries. In the list box, it is set to use only 1 processor. I set
it to use 2 processors, and click Apply, and then OK. When I go back
to the dialog box, it is set to use only 1 processor again, as if I
had never set the option. When I run sp_configure, it would indicate
that I have, in fact, set the parallel execution to use 2 processors
(max degree of parallelism = 2). It's only from the processor tab
that I think I've only set it to use 1 processor.
Is there a way I can verify that 2 processors are getting used in the
query parallelism? Or is it possible that another configuration
setting is preventing this from happening?
Here is the complete sp_configure, if it helps:
affinity mask 0 2147483647 0 0
allow updates 0 1 1 1
cost threshold for parallelism 0 32767 5 5
cursor threshold -1 2147483647 -1 -1
default language 0 9999 0 0
default sortorder id 0 255 52 52
extended memory size (MB) 0 2147483647 0 0
fill factor (%) 0 100 0 0
index create memory (KB) 704 1600000 0 0
language in cache 3 100 3 3
language neutral full-text 0 1 0 0
lightweight pooling 0 1 0 0
locks 5000 2147483647 0 0
max async IO 1 255 32 32
max degree of parallelism 0 32 2 2
max server memory (MB) 4 2147483647 5500 5500
max text repl size (B) 0 2147483647 65536 65536
max worker threads 10 1024 500 500
media retention 0 365 0 0
min memory per query (KB) 512 2147483647 1024 1024
min server memory (MB) 0 2147483647 5500 5500
nested triggers 0 1 1 1
network packet size (B) 512 65535 4096 4096
open objects 0 2147483647 0 0
priority boost 0 1 1 1
query governor cost limit 0 2147483647 0 0
query wait (s) -1 2147483647 -1 -1
recovery interval (min) 0 32767 0 0
remote access 0 1 1 1
remote login timeout (s) 0 2147483647 5 5
remote proc trans 0 1 0 0
remote query timeout (s) 0 2147483647 0 0
resource timeout (s) 5 2147483647 10 10
scan for startup procs 0 1 0 0
set working set size 0 1 1 1
show advanced options 0 1 1 1
spin counter 1 2147483647 20000 20000
time slice (ms) 50 1000 100 100
two digit year cutoff 1753 9999 2049 2049
Unicode comparison style 0 2147483647 196609 196609
Unicode locale id 0 2147483647 1033 1033
user connections 0 32767 0 0
user options 0 4095 0 0Sp_configure looks right. Might be a bug in EM?
Kevin Connell, MCDBA
----
The views expressed here are my own
and not of my employer.
----
"AAAWalrus" <aaawalrus@.yahoo.com> wrote in message
news:8b266bc2.0311110819.3541dc88@.posting.google.com...
> I am working with a SQL Server 7 (SP4) box with 8 processors. When I
> bring up Enterprise Manager and go to the Processor tab under server
> properties, I can see the configuration for the parallel execution of
> queries. In the list box, it is set to use only 1 processor. I set
> it to use 2 processors, and click Apply, and then OK. When I go back
> to the dialog box, it is set to use only 1 processor again, as if I
> had never set the option. When I run sp_configure, it would indicate
> that I have, in fact, set the parallel execution to use 2 processors
> (max degree of parallelism = 2). It's only from the processor tab
> that I think I've only set it to use 1 processor.
> Is there a way I can verify that 2 processors are getting used in the
> query parallelism? Or is it possible that another configuration
> setting is preventing this from happening?
> Here is the complete sp_configure, if it helps:
> affinity mask 0 2147483647 0 0
> allow updates 0 1 1 1
> cost threshold for parallelism 0 32767 5 5
> cursor threshold -1 2147483647 -1 -1
> default language 0 9999 0 0
> default sortorder id 0 255 52 52
> extended memory size (MB) 0 2147483647 0 0
> fill factor (%) 0 100 0 0
> index create memory (KB) 704 1600000 0 0
> language in cache 3 100 3 3
> language neutral full-text 0 1 0 0
> lightweight pooling 0 1 0 0
> locks 5000 2147483647 0 0
> max async IO 1 255 32 32
> max degree of parallelism 0 32 2 2
> max server memory (MB) 4 2147483647 5500 5500
> max text repl size (B) 0 2147483647 65536 65536
> max worker threads 10 1024 500 500
> media retention 0 365 0 0
> min memory per query (KB) 512 2147483647 1024 1024
> min server memory (MB) 0 2147483647 5500 5500
> nested triggers 0 1 1 1
> network packet size (B) 512 65535 4096 4096
> open objects 0 2147483647 0 0
> priority boost 0 1 1 1
> query governor cost limit 0 2147483647 0 0
> query wait (s) -1 2147483647 -1 -1
> recovery interval (min) 0 32767 0 0
> remote access 0 1 1 1
> remote login timeout (s) 0 2147483647 5 5
> remote proc trans 0 1 0 0
> remote query timeout (s) 0 2147483647 0 0
> resource timeout (s) 5 2147483647 10 10
> scan for startup procs 0 1 0 0
> set working set size 0 1 1 1
> show advanced options 0 1 1 1
> spin counter 1 2147483647 20000 20000
> time slice (ms) 50 1000 100 100
> two digit year cutoff 1753 9999 2049 2049
> Unicode comparison style 0 2147483647 196609 196609
> Unicode locale id 0 2147483647 1033 1033
> user connections 0 32767 0 0
> user options 0 4095 0 0|||You can either inspect the query execution plan (should see parallelism for
queries/subqueries that cost more than 5)
or/and to take a look in Processor Usage in Performance Monitor if you can
afford to be the only one to make traffic on the server
at certain time
Uzytkownik "AAAWalrus" <aaawalrus@.yahoo.com> napisal w wiadomosci
news:8b266bc2.0311110819.3541dc88@.posting.google.com...
> I am working with a SQL Server 7 (SP4) box with 8 processors. When I
> bring up Enterprise Manager and go to the Processor tab under server
> properties, I can see the configuration for the parallel execution of
> queries. In the list box, it is set to use only 1 processor. I set
> it to use 2 processors, and click Apply, and then OK. When I go back
> to the dialog box, it is set to use only 1 processor again, as if I
> had never set the option. When I run sp_configure, it would indicate
> that I have, in fact, set the parallel execution to use 2 processors
> (max degree of parallelism = 2). It's only from the processor tab
> that I think I've only set it to use 1 processor.
> Is there a way I can verify that 2 processors are getting used in the
> query parallelism? Or is it possible that another configuration
> setting is preventing this from happening?
> Here is the complete sp_configure, if it helps:
> affinity mask 0 2147483647 0 0
> allow updates 0 1 1 1
> cost threshold for parallelism 0 32767 5 5
> cursor threshold -1 2147483647 -1 -1
> default language 0 9999 0 0
> default sortorder id 0 255 52 52
> extended memory size (MB) 0 2147483647 0 0
> fill factor (%) 0 100 0 0
> index create memory (KB) 704 1600000 0 0
> language in cache 3 100 3 3
> language neutral full-text 0 1 0 0
> lightweight pooling 0 1 0 0
> locks 5000 2147483647 0 0
> max async IO 1 255 32 32
> max degree of parallelism 0 32 2 2
> max server memory (MB) 4 2147483647 5500 5500
> max text repl size (B) 0 2147483647 65536 65536
> max worker threads 10 1024 500 500
> media retention 0 365 0 0
> min memory per query (KB) 512 2147483647 1024 1024
> min server memory (MB) 0 2147483647 5500 5500
> nested triggers 0 1 1 1
> network packet size (B) 512 65535 4096 4096
> open objects 0 2147483647 0 0
> priority boost 0 1 1 1
> query governor cost limit 0 2147483647 0 0
> query wait (s) -1 2147483647 -1 -1
> recovery interval (min) 0 32767 0 0
> remote access 0 1 1 1
> remote login timeout (s) 0 2147483647 5 5
> remote proc trans 0 1 0 0
> remote query timeout (s) 0 2147483647 0 0
> resource timeout (s) 5 2147483647 10 10
> scan for startup procs 0 1 0 0
> set working set size 0 1 1 1
> show advanced options 0 1 1 1
> spin counter 1 2147483647 20000 20000
> time slice (ms) 50 1000 100 100
> two digit year cutoff 1753 9999 2049 2049
> Unicode comparison style 0 2147483647 196609 196609
> Unicode locale id 0 2147483647 1033 1033
> user connections 0 32767 0 0
> user options 0 4095 0 0|||the best way is to use profiler, capture the classes for degree of
parallelism.
BTW, just having a cost of 5 does not guarentee parallism, only certain
query plan operators can be run in parallel.
--
Kevin Connell, MCDBA
----
The views expressed here are my own
and not of my employer.
----
"Tomasz" <tp@.nospam.com> wrote in message
news:efKp2EHqDHA.2444@.TK2MSFTNGP09.phx.gbl...
> You can either inspect the query execution plan (should see parallelism
for
> queries/subqueries that cost more than 5)
> or/and to take a look in Processor Usage in Performance Monitor if you can
> afford to be the only one to make traffic on the server
> at certain time
> Uzytkownik "AAAWalrus" <aaawalrus@.yahoo.com> napisal w wiadomosci
> news:8b266bc2.0311110819.3541dc88@.posting.google.com...
> > I am working with a SQL Server 7 (SP4) box with 8 processors. When I
> > bring up Enterprise Manager and go to the Processor tab under server
> > properties, I can see the configuration for the parallel execution of
> > queries. In the list box, it is set to use only 1 processor. I set
> > it to use 2 processors, and click Apply, and then OK. When I go back
> > to the dialog box, it is set to use only 1 processor again, as if I
> > had never set the option. When I run sp_configure, it would indicate
> > that I have, in fact, set the parallel execution to use 2 processors
> > (max degree of parallelism = 2). It's only from the processor tab
> > that I think I've only set it to use 1 processor.
> >
> > Is there a way I can verify that 2 processors are getting used in the
> > query parallelism? Or is it possible that another configuration
> > setting is preventing this from happening?
> >
> > Here is the complete sp_configure, if it helps:
> >
> > affinity mask 0 2147483647 0 0
> > allow updates 0 1 1 1
> > cost threshold for parallelism 0 32767 5 5
> > cursor threshold -1 2147483647 -1 -1
> > default language 0 9999 0 0
> > default sortorder id 0 255 52 52
> > extended memory size (MB) 0 2147483647 0 0
> > fill factor (%) 0 100 0 0
> > index create memory (KB) 704 1600000 0 0
> > language in cache 3 100 3 3
> > language neutral full-text 0 1 0 0
> > lightweight pooling 0 1 0 0
> > locks 5000 2147483647 0 0
> > max async IO 1 255 32 32
> > max degree of parallelism 0 32 2 2
> > max server memory (MB) 4 2147483647 5500 5500
> > max text repl size (B) 0 2147483647 65536 65536
> > max worker threads 10 1024 500 500
> > media retention 0 365 0 0
> > min memory per query (KB) 512 2147483647 1024 1024
> > min server memory (MB) 0 2147483647 5500 5500
> > nested triggers 0 1 1 1
> > network packet size (B) 512 65535 4096 4096
> > open objects 0 2147483647 0 0
> > priority boost 0 1 1 1
> > query governor cost limit 0 2147483647 0 0
> > query wait (s) -1 2147483647 -1 -1
> > recovery interval (min) 0 32767 0 0
> > remote access 0 1 1 1
> > remote login timeout (s) 0 2147483647 5 5
> > remote proc trans 0 1 0 0
> > remote query timeout (s) 0 2147483647 0 0
> > resource timeout (s) 5 2147483647 10 10
> > scan for startup procs 0 1 0 0
> > set working set size 0 1 1 1
> > show advanced options 0 1 1 1
> > spin counter 1 2147483647 20000 20000
> > time slice (ms) 50 1000 100 100
> > two digit year cutoff 1753 9999 2049 2049
> > Unicode comparison style 0 2147483647 196609 196609
> > Unicode locale id 0 2147483647 1033 1033
> > user connections 0 32767 0 0
> > user options 0 4095 0 0
>|||I am chalking this up to a bug in the SQL 7 Enterprise Manager. When
I view the same option on the SQL 7 database from SQL 2000 Enterprise
Manager (personal edition installed on my PC), it properly updates and
shows the number of processors to use on parallel queries. What makes
me a little worried, though, is that I have not found a relative MS
support article. I've been contemplating calling MS support about it,
but that's a whole other set of hassles.
Thanks for your help!
"Kevin" <ReplyTo@.Newsgroups.only> wrote in message news:<#JdolkHqDHA.1676@.TK2MSFTNGP09.phx.gbl>...
> the best way is to use profiler, capture the classes for degree of
> parallelism.
> BTW, just having a cost of 5 does not guarentee parallism, only certain
> query plan operators can be run in parallel.
> --
> Kevin Connell, MCDBA
> ----
> The views expressed here are my own
> and not of my employer.
> ----
> "Tomasz" <tp@.nospam.com> wrote in message
> news:efKp2EHqDHA.2444@.TK2MSFTNGP09.phx.gbl...
> > You can either inspect the query execution plan (should see parallelism
> for
> > queries/subqueries that cost more than 5)
> > or/and to take a look in Processor Usage in Performance Monitor if you can
> > afford to be the only one to make traffic on the server
> > at certain time

Query Parallelism (maxdop)

I have 4 processor SQL server. When I run this query in query analyzer
(two table joins with wly aggregation approx 500,000 rows each) ...
it takes only 7 seconds... when I run it in a stored procedure... it
takes about 60 minutes. I dont see parallelism in the execution plan of
SP... I have already tried hint maxdop... it did'nt work... Im not
sure what I might be running into'
Any help is greatly appreciated...Google "parameter sniffing".
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
.
"zomer" <noneee@.gmail.com> wrote in message
news:1145384015.190289.310680@.e56g2000cwe.googlegroups.com...
I have 4 processor SQL server. When I run this query in query analyzer
(two table joins with wly aggregation approx 500,000 rows each) ...
it takes only 7 seconds... when I run it in a stored procedure... it
takes about 60 minutes. I dont see parallelism in the execution plan of
SP... I have already tried hint maxdop... it did'nt work... Im not
sure what I might be running into'
Any help is greatly appreciated...|||Try using WITH RECOMPILE on your stored procedure just as an initial test.
It may be getting a less than optimal execution plan. See
http://www.dbtalk.net/microsoft-pub...ter-203396.html
for some thoughts.
I'm running into some similar issues with ADO taking ludicrously long while
Query Analyzer goes quickly. Haven't tracked down the exact cause yet,
though it appears many other people have had the same issue.
Mike
"zomer" <noneee@.gmail.com> wrote in message
news:1145384015.190289.310680@.e56g2000cwe.googlegroups.com...
>I have 4 processor SQL server. When I run this query in query analyzer
> (two table joins with wly aggregation approx 500,000 rows each) ...
> it takes only 7 seconds... when I run it in a stored procedure... it
> takes about 60 minutes. I dont see parallelism in the execution plan of
> SP... I have already tried hint maxdop... it did'nt work... Im not
> sure what I might be running into'
> Any help is greatly appreciated...
>|||Tom -
Are there other things besides the parameter sniffing that could cause the
performance difference?
I'm running into a similar problem, except here's what's happening:
1. I have SQL Profiler on in production.
2. I catch the "slow" procedure
3. Immediately I copy and paste the text into Query Analyzer and execute the
query on the same production server -- and it executes quickly.
Same parameters. Same execution plan I would think (I'm not seeing any
recompiles). The parameter sniffing discussion made sense but it doesn't
seem to fit this scenario since the procedure is already compiled and I'm
executing it with the same paramters that made it run slow from the app.
Thanks for any help,
Mike
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:ucLVCUxYGHA.3880@.TK2MSFTNGP04.phx.gbl...
> Google "parameter sniffing".
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> .
> "zomer" <noneee@.gmail.com> wrote in message
> news:1145384015.190289.310680@.e56g2000cwe.googlegroups.com...
> I have 4 processor SQL server. When I run this query in query analyzer
> (two table joins with wly aggregation approx 500,000 rows each) ...
> it takes only 7 seconds... when I run it in a stored procedure... it
> takes about 60 minutes. I dont see parallelism in the execution plan of
> SP... I have already tried hint maxdop... it did'nt work... Im not
> sure what I might be running into'
> Any help is greatly appreciated...
>|||I'd take a close look at the Execution Plan for each (sproc and QA runs) -
sounds like it's not using an index somewhere along the line.
HTH
"zomer" wrote:

> I have 4 processor SQL server. When I run this query in query analyzer
> (two table joins with wly aggregation approx 500,000 rows each) ...
> it takes only 7 seconds... when I run it in a stored procedure... it
> takes about 60 minutes. I dont see parallelism in the execution plan of
> SP... I have already tried hint maxdop... it did'nt work... Im not
> sure what I might be running into'
> Any help is greatly appreciated...
>|||More info for my previous post: When I profiled SP:Stmt Starting and
SP:StmtEnding, the application executed query showed the length of the
SELECT statements as being lengthened (there are multiple result sets
returned). ALL of the indivdual SELECTs were propotionally slower.
To me this seems to be some type of interaction problem between ADO and SQL
Server, not a SQL Server performance issue. The ADO client uses client side
cursors. This brings up the question: Can slow response on the
SQLOLEDB/ADO driver side affect duration times in SQL Profiler ?
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:ucLVCUxYGHA.3880@.TK2MSFTNGP04.phx.gbl...
> Google "parameter sniffing".
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> .
> "zomer" <noneee@.gmail.com> wrote in message
> news:1145384015.190289.310680@.e56g2000cwe.googlegroups.com...
> I have 4 processor SQL server. When I run this query in query analyzer
> (two table joins with wly aggregation approx 500,000 rows each) ...
> it takes only 7 seconds... when I run it in a stored procedure... it
> takes about 60 minutes. I dont see parallelism in the execution plan of
> SP... I have already tried hint maxdop... it did'nt work... Im not
> sure what I might be running into'
> Any help is greatly appreciated...
>|||I think what you're seeing is data and/or plan caching - and that's by
design. When a query first enters SQL Server, a plan is created and cached.
This takes time. Upon subsequent execution, the original plan is (likely)
used, and this goes faster. However, any data that were read by the
just-executed query are likely now in data cache. Thus, the next time the
query is run, it's getting the data from cache - not from disk. The more
RAM you have, the bigger the cache you have - and the faster (in most cases)
that SQL Server will run.
If you want a pure apples to apples comparison, run the following before
each test:
DBCC FREEPROCCACHE
DBCC DROPCLEANBUFFERS
This flushes the proc and data caches, respectively. Now, you get a fresh
plan - and you get your data from disk. A subsequent run without running
these DBCC's should go significantly faster.
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
.
"Mike Jansen" <mjansen_nntp@.mail.com> wrote in message
news:uTK$ihxYGHA.1192@.TK2MSFTNGP03.phx.gbl...
Tom -
Are there other things besides the parameter sniffing that could cause the
performance difference?
I'm running into a similar problem, except here's what's happening:
1. I have SQL Profiler on in production.
2. I catch the "slow" procedure
3. Immediately I copy and paste the text into Query Analyzer and execute the
query on the same production server -- and it executes quickly.
Same parameters. Same execution plan I would think (I'm not seeing any
recompiles). The parameter sniffing discussion made sense but it doesn't
seem to fit this scenario since the procedure is already compiled and I'm
executing it with the same paramters that made it run slow from the app.
Thanks for any help,
Mike
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:ucLVCUxYGHA.3880@.TK2MSFTNGP04.phx.gbl...
> Google "parameter sniffing".
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> .
> "zomer" <noneee@.gmail.com> wrote in message
> news:1145384015.190289.310680@.e56g2000cwe.googlegroups.com...
> I have 4 processor SQL server. When I run this query in query analyzer
> (two table joins with wly aggregation approx 500,000 rows each) ...
> it takes only 7 seconds... when I run it in a stored procedure... it
> takes about 60 minutes. I dont see parallelism in the execution plan of
> SP... I have already tried hint maxdop... it did'nt work... Im not
> sure what I might be running into'
> Any help is greatly appreciated...
>|||Im glad you mentioned that... the only difference of execution plan is
that the if I use query analyzer... it uses parallelism while stored
procedure does not. Why is it so' The server load is pretty
consistent.|||You may want to search on "firehose cursor".
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
.
"Mike Jansen" <mjansen_nntp@.mail.com> wrote in message
news:e%236DQxxYGHA.3832@.TK2MSFTNGP04.phx.gbl...
> Duration on the Profiler is the time between receiving the statement and
> the
> last row being retrieved.
Cool. That's what I was suspecting.

> My guess is that your ADO may not be optimal.
It's a single call to Recordset.Open with a client side cursor so there's
not much other than tuning some settings I can do. I think its time to take
this issue to the ADO forum. Thanks for all your input.
Mike|||I'm thinking it's ADO-related.
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
.
"zomer" <noneee@.gmail.com> wrote in message
news:1145387868.100688.258810@.e56g2000cwe.googlegroups.com...
yes... datatypes are the same.