Parameter box does not autosize while Multi Select.

Hi all Gurus
In reports when I set the Multi Select option for parameters then size
of parameter box does not increase according to Length of parameter
string value. It remains fix at default values and I have to scroll
horizontally to see full parameter string , this is very tuff because
our parameter strings are very large.
Is there anyway to overcome this problem?
ThanksOn Apr 16, 9:03 am, sqlpr...@.gmail.com wrote:
> Hi all Gurus
> In reports when I set the Multi Select option for parameters then size
> of parameter box does not increase according to Length of parameter
> string value. It remains fix at default values and I have to scroll
> horizontally to see full parameter string , this is very tuff because
> our parameter strings are very large.
> Is there anyway to overcome this problem?
> Thanks
As far as I know, there is not. Of course, you could develop an
ASP.NET application that would allow for you to have more flexibility.
Regards,
Enrique Martinez
Sr. Software Consultant|||On Apr 17, 12:06 am, "EMartinez" <emartinez...@.gmail.com> wrote:
> On Apr 16, 9:03 am, sqlpr...@.gmail.com wrote:
> > Hi all Gurus
> > In reports when I set the Multi Select option for parameters then size
> > of parameter box does not increase according to Length of parameter
> > string value. It remains fix at default values and I have to scroll
> > horizontally to see full parameter string , this is very tuff because
> > our parameter strings are very large.
> > Is there anyway to overcome this problem?
> > Thanks
> As far as I know, there is not. Of course, you could develop an
> ASP.NET application that would allow for you to have more flexibility.
> Regards,
> Enrique Martinez
> Sr. Software Consultant
Microsoft must have to provide support this type of basic requirement
Rregards

Parallelism Question

If SQL Server is designed for multi processor systems, how can running
a query in parallel make such a dramatic difference to performance ?

We have a reasonably simple query which brings in data from a few none
complex views. If we run it on our 2x2.4Ghz Xeon server it takes 6
minutes plus to run. If we run this on the same server with
OPTION(MAXDOP 1) at the end of the same query it takes less than a
second.

Examining the execution plan, the only difference I have been able to
see is that parallelism is taking up 96% of the run time when using
two processors. This drops when using the one so a sort takes up the
vast majority of the time for the query to run.

OK, so running in parallel should mean that it's run in various parts
and then 'joined up' later for performance gains, but how can it get
it so wrong (timewise) ?

If this is the case, will I see a significant difference changing our
server to use a single processor, which seems completely the wrong
approach (or should I do this on each query in each app - eek) ?

Do we have a problem that we don't know about that causes it to take
this long ?

What can we do ? Ideally, using both processors would seem to be
preferrable.We've changed the server to use a single processor at the moment and
the report that my query is based on works almost instantly. We're
waiting to see what effect this has for other users, but so far,
no-one has complained.

Are we wasting a second processor ?|||"Ryan" <ryanofford@.hotmail.com> wrote in message
news:7802b79d.0312160816.68d60164@.posting.google.c om...
> We've changed the server to use a single processor at the moment and
> the report that my query is based on works almost instantly. We're
> waiting to see what effect this has for other users, but so far,
> no-one has complained.
> Are we wasting a second processor ?

No. There are definitely times it can help.

You may want to open a ticket with MS. In general, when the query optimizer
finds such a poor optimization they consider it a bug. (If you can, review
Kalen Delaney's article in this month's SQL Server Magazine.)