Last try: Polling the network for SQL servers, including named instances

Hopefully I do not end up empty-handed.
Hi group,
I am trying to get a list of SQL Server installations running on the
network. I tried to use sqlcmd -L (or osql -L). However, when I do this
from my box the named instances do not show up, whereas when it is run from
a server box those instances do get listed.
What is required to make the command return the full list? Is there other
(simple) way to do it?
Thanks.
QuentinThe -L option will not give you the 'full list' in most cases. The most
reliable way I found is to enumerate the servers in a network/domain, and for
each server run a multiplicity of tests to see whether there are SQL instance
running or installed (e.g. checking for the SQL services. interrogating the
registry for a list of installed SQL instances). This approach can be time
consuming in a large network, and the network security may not like it.
Ideally, you should have some type of inentory in place and updated so that
you don't have to do this.
Exactly how you want to do this and whether you can simplify the work to get
it done depend on a number of factors: (1) how reliable you want this list to
be, and (2) the specifics of your environment. For instance, if you know that
you can count on your SQL Browser running on the SQL boxes, you could just
enumerate your servers, and run SQLPing.exe against each to get a list.
Linchi
"Quentin Ran" wrote:
> Hopefully I do not end up empty-handed.
> Hi group,
> I am trying to get a list of SQL Server installations running on the
> network. I tried to use sqlcmd -L (or osql -L). However, when I do this
> from my box the named instances do not show up, whereas when it is run from
> a server box those instances do get listed.
> What is required to make the command return the full list? Is there other
> (simple) way to do it?
> Thanks.
> Quentin
>
>
>|||Thanks Linchi.
independent of what I want to use it for, the fact that sqlcmd -L returns
different results when run from differnet servers makes it interesting, if
not bizzare ...
Quentin
"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:0C43A8EF-CF62-45F4-B060-CC72396CDEE4@.microsoft.com...
> The -L option will not give you the 'full list' in most cases. The most
> reliable way I found is to enumerate the servers in a network/domain, and
> for
> each server run a multiplicity of tests to see whether there are SQL
> instance
> running or installed (e.g. checking for the SQL services. interrogating
> the
> registry for a list of installed SQL instances). This approach can be time
> consuming in a large network, and the network security may not like it.
> Ideally, you should have some type of inentory in place and updated so
> that
> you don't have to do this.
> Exactly how you want to do this and whether you can simplify the work to
> get
> it done depend on a number of factors: (1) how reliable you want this list
> to
> be, and (2) the specifics of your environment. For instance, if you know
> that
> you can count on your SQL Browser running on the SQL boxes, you could just
> enumerate your servers, and run SQLPing.exe against each to get a list.
> Linchi
> "Quentin Ran" wrote:
>> Hopefully I do not end up empty-handed.
>> Hi group,
>> I am trying to get a list of SQL Server installations running on the
>> network. I tried to use sqlcmd -L (or osql -L). However, when I do this
>> from my box the named instances do not show up, whereas when it is run
>> from
>> a server box those instances do get listed.
>> What is required to make the command return the full list? Is there
>> other
>> (simple) way to do it?
>> Thanks.
>> Quentin
>>
>>

Large Slowly Changing Dimension

Hello,
I'm somewhat new to data warehousing, and have some basic questions.
Let's say I have a fact table, named sales. The financial analyst
would like to be able to sort the sales information based on several
customer related attributes. Some of these attributes would include
zip code, age, and income. While I can create a customer dimension,
these attributes change over time.
The analysts are really only interested in these customer attributes
at the time of the sale. For example, they only care about where a
customer lived at the time of the sale, but not where they are living
now. Now I know there are different techniques for dealing with
changing dimensions, but I'm left with the impression that it would be
making things more complicated then necessary.
Would it not be best to just simply store this information in the
fact table itself? While I'm aware that fact tables are primarily used
to store numerical information, I don't see the advantage of putting
this information in a separate dimension.
Your input would be much appreciated.
Thanks,
AttilaHi,
You say the analysts are interested in the customer attributes at the time
of the sale. So these attributes will have to be stored in dimensions to be
able to analyse them using datawarehouse techniques. These must be slowly
changing. So when you add more salesfacts, e.g. with a zipcode that doesnt
exist in the zipcode dimension yet, you'll have to add it to the dimension.
The alternative is to drop and recreate all the facts and dimensions, but
that's no option if the customers move or the incomes change in the source
system.
Good luck...
Jeroen.
"Attila" <ThisIsAFakeAddress35@.hotmail.com> wrote in message
news:9516751f.0401290847.23e49471@.posting.google.com...

quote:

---

> Hello,
> I'm somewhat new to data warehousing, and have some basic questions.
> Let's say I have a fact table, named sales. The financial analyst
> would like to be able to sort the sales information based on several
> customer related attributes. Some of these attributes would include
> zip code, age, and income. While I can create a customer dimension,
> these attributes change over time.
> The analysts are really only interested in these customer attributes
> at the time of the sale. For example, they only care about where a
> customer lived at the time of the sale, but not where they are living
> now. Now I know there are different techniques for dealing with
> changing dimensions, but I'm left with the impression that it would be
> making things more complicated then necessary.
> Would it not be best to just simply store this information in the
> fact table itself? While I'm aware that fact tables are primarily used
> to store numerical information, I don't see the advantage of putting
> this information in a separate dimension.
> Your input would be much appreciated.
> Thanks,
> Attila

---

|||> So these attributes will have to be stored in dimensions to be
able to analyse them using datawarehouse techniques.
Can you elaborate on this part? What specifically will an analyst not
be able to do if I store the customer data in the fact table?
Thanks,
Attila
"Spike" <jeroenaNOSPAM@.hotmail.com> wrote in message news:<bvgf14$sjl$1@.reader08.wxs.nl>...[QUOTE]
> Hi,
> You say the analysts are interested in the customer attributes at the time
> of the sale. So these attributes will have to be stored in dimensions to b
e
> able to analyse them using datawarehouse techniques. These must be slowly
> changing. So when you add more salesfacts, e.g. with a zipcode that doesnt
> exist in the zipcode dimension yet, you'll have to add it to the dimension
.
> The alternative is to drop and recreate all the facts and dimensions, but
> that's no option if the customers move or the incomes change in the source
> system.
> Good luck...
> Jeroen.
> "Attila" <ThisIsAFakeAddress35@.hotmail.com> wrote in message
> news:9516751f.0401290847.23e49471@.posting.google.com...|||I suggest reading articles written by Ralph Kimball. Here's one of his
classic articles on slowly changing dimensions.
http://www.dbmsmag.com/9604d05.html
"Attila" <ThisIsAFakeAddress35@.hotmail.com> wrote in message
news:9516751f.0402020643.36d448b7@.posting.google.com...
> able to analyse them using datawarehouse techniques.
> Can you elaborate on this part? What specifically will an analyst not
> be able to do if I store the customer data in the fact table?
> Thanks,
> Attila
>
> "Spike" <jeroenaNOSPAM@.hotmail.com> wrote in message
news:<bvgf14$sjl$1@.reader08.wxs.nl>...
time
be
slowly
doesnt
dimension.
but
source|||There is an entire chapter in Ralph Kimballs book on mini dimensions,
which help to stabilise the pain of rapidly changing dimensions.
Ashish
On Tue, 17 Feb 2004 15:29:51 -0500, Domenico Discepola
<domenico_discepola@.quadrachemicals.com> wrote:

> I suggest reading articles written by Ralph Kimball. Here's one of his
> classic articles on slowly changing dimensions.
> http://www.dbmsmag.com/9604d05.html
>
> "Attila" <ThisIsAFakeAddress35@.hotmail.com> wrote in message
> news:9516751f.0402020643.36d448b7@.posting.google.com...
> news:<bvgf14$sjl$1@.reader08.wxs.nl>...
> time
> be
> slowly
> doesnt
> dimension.
> but
> source
>
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/