Multiple Instances of Sql Server on a machine.

We are currently writing software that connects to Sql server 2000. We use a
connection string that provides the name of the server machine that
sql-server resides on. What do we do when there is more than one sql-server
on that machine. For example, there are instances A,B, and C on the machine
and we want to work with instance B. What changes do we need to make to our
connection string to make this happen? We aren't using DSN's by the way.
Thanks in advance for any assistance.Ed Hawkes wrote:
> We are currently writing software that connects to Sql server 2000.
> We use a connection string that provides the name of the server
> machine that sql-server resides on. What do we do when there is more
> than one sql-server on that machine. For example, there are instances
> A,B, and C on the machine and we want to work with instance B. What
> changes do we need to make to our connection string to make this
> happen? We aren't using DSN's by the way. Thanks in advance for any
> assistance.
Provide the instance name (SERVERNAME\INSTANCENAME)
David Gugick
Imceda Software
www.imceda.com

multiple blob

A table has a text field which provides content on a web page.
If the web content was to be regionalised, what would be the pros/cons of
having a text field for each region in the same record?
Thanks Soc.The main downside IMHO would be a total loss of scalability. Why not just us
e
the ntext datatype? That way you can just keep all in one column. Look up us
e
of unicode data types in Books Online.
ML|||How would you keep them all in one column? The ntext datatype only allows
unicode characters, not special regionlization (unless I am about to learn
something :)
----
Louis Davidson - http://spaces.msn.com/members/drsql/
SQL Server MVP
"Arguments are to be avoided: they are always vulgar and often convincing."
(Oscar Wilde)
"ML" <ML@.discussions.microsoft.com> wrote in message
news:73A4CA11-1D30-4C0E-92D1-A72187B07E62@.microsoft.com...
> The main downside IMHO would be a total loss of scalability. Why not just
> use
> the ntext datatype? That way you can just keep all in one column. Look up
> use
> of unicode data types in Books Online.
>
> ML|||That's not exactly what I meant, but hey, why not?
ItemID : LanguageID : Text
Or did you mean all of them in one row? Now, that even I can't imagine. :)
No, wait... I can! If all they're inside an XML. But that's just silly, righ
t?
E.g. ItemID : XML
Item Text
BookTitle <values>
<value language="english">A summer night's
dream</value>
<value language="Deutsch">Ein sommer Nachts
Traum</value>
</values>
ML|||I didn't figure it was really what you meant. But you are right, you could
use XML, depending on the actual needs.
----
Louis Davidson - http://spaces.msn.com/members/drsql/
SQL Server MVP
"Arguments are to be avoided: they are always vulgar and often convincing."
(Oscar Wilde)
"ML" <ML@.discussions.microsoft.com> wrote in message
news:AE81E10E-DBEF-4FD7-B5E6-38C9AA2CF27A@.microsoft.com...
> That's not exactly what I meant, but hey, why not?
> ItemID : LanguageID : Text
> Or did you mean all of them in one row? Now, that even I can't imagine. :)
> No, wait... I can! If all they're inside an XML. But that's just silly,
> right?
> E.g. ItemID : XML
> Item Text
> BookTitle <values>
> <value language="english">A summer night's
> dream</value>
> <value language="Deutsch">Ein sommer Nachts
> Traum</value>
> </values>
>
> ML|||On Fri, 9 Sep 2005 16:12:16 +0100, soc wrote:

>A table has a text field which provides content on a web page.
>If the web content was to be regionalised, what would be the pros/cons of
>having a text field for each region in the same record?
>Thanks Soc.
>
Hi Soc,
Pros: none that I can think of.
Cons: not normalised, not scalable.
Better to have an extra table, with foreign key to the main table,
language code plus this foreign key as the primary key and the
translated contents as the third column.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||Thanks all.
I agree with the separate table option...
"Hugo Kornelis" <hugo@.pe_NO_rFact.in_SPAM_fo> wrote in message
news:4804i1pd5an6r5jl1m42rttos800j7sapt@.
4ax.com...
> On Fri, 9 Sep 2005 16:12:16 +0100, soc wrote:
>
> Hi Soc,
> Pros: none that I can think of.
> Cons: not normalised, not scalable.
> Better to have an extra table, with foreign key to the main table,
> language code plus this foreign key as the primary key and the
> translated contents as the third column.
> Best, Hugo
> --
> (Remove _NO_ and _SPAM_ to get my e-mail address)
>

Multi-Parameter (Select All) Detection in SSRS 2005?

I'd like to know if SSRS provides a way to determine if all rows are selected from a multi_valued parameter dropdown list? I thought of how I could do this programmatically, but didn't want to build something that is already in the product (if it exists that is). Thanks.

There is no built-in functionality, but here are some ideas:

* if the multi value parameter has a pre-defined (constant) list of valid values, you know how many values are available for selection. The report parameters in RS 2005 expose a new property called .Count which tells you the count of selected parameter values (e.g. =Parameters!P1.Count). Hence, you could compare the count of the selected values with the count of the total values.

* if the multi value parameter has a dataset-based valid values list, you could just use the same field in a CountDistinct aggregate function to determine how many valid values are available, e.g. =CountDistinct(Fields!A.Value) and compare it again with the Count of selected values.

-- Robert

|||Thank you Robert. I forgot about CountDistinct.