Thursday, March 29, 2012

Description for Configuration Values

Hi,
From where can I get the description for the Config Values for both SQL
2000 and SQL 2005
Similar to the one that SQL-DMO returns when queried for the description
of a particular configuration values, is it stored in some system tables.
The comment field gives very little information about the configuration
value as compared to the description given by SQL-DMO.
Also, the description field value in SQL 2005 is not the same when
queried through SQL-DMO.
e.g. In the table sys.configurations the config value "affinity mask"
has description "affinity mask"
but when queried thru SQL-DMO it gives the following
"Indicates which processors SQL Server may use (default is 0, or any).
A non-zero value is interpreted as a bit mask; e.g, processors 1, 2, and 5
are specified with a hexadecimal value of 0x13 or the decimal equivalent
of 19."
TIA
PraHi, Pra
It seems that these descriptions are stored in the SQLDMO.RLL file, so
I see no easy way of retrieiving them from T-SQL (since these
descriptions are not stored in any system table).
Razvan|||Thanks Razvan
Can u tell me one more thing how can I relate the config value with the
message.
Thanks
Pra
"Razvan Socol" <rsocol@.gmail.com> wrote in message
news:1139988679.719312.27840@.g47g2000cwa.googlegroups.com...
> Hi, Pra
> It seems that these descriptions are stored in the SQLDMO.RLL file, so
> I see no easy way of retrieiving them from T-SQL (since these
> descriptions are not stored in any system table).
> Razvan
>|||Hi, Pra
You can use SQL-DMO to iterate through the each of the values in the
ConfigValues collection to get the Name and Description properties and
store them in your own table.
You may also want to take a look at:
http://msdn2.microsoft.com/en-us/library/ms131974.aspx
[url]http://msdn.microsoft.com/library/en-us/sqldmo/dmoref_cnst02_2w9x.asp?frame=true[/
url]
to check if you have found all the documented configuration values in
the ConfigValues collection.
Razvan|||Thanks
But I cant do that. Any other way.
Pra
"Razvan Socol" <rsocol@.gmail.com> wrote in message
news:1140002871.149041.272720@.z14g2000cwz.googlegroups.com...
> Hi, Pra
> You can use SQL-DMO to iterate through the each of the values in the
> ConfigValues collection to get the Name and Description properties and
> store them in your own table.
> You may also want to take a look at:
> http://msdn2.microsoft.com/en-us/library/ms131974.aspx
> http://msdn.microsoft.com/library/e...me=true

> to check if you have found all the documented configuration values in
> the ConfigValues collection.
> Razvan
>|||Hi, Pra
Please tell me the reason why you can't do that, so I can think of
another way that works (not another way that you can't do, either). You
can also state the overall scenario of what you are trying to do with
the description and why you need this description instead of the
description from the sys.configurations table.
In the mean time, I would say that you can invoke the SQL-DMO code from
T-SQL using the sp_OACreate / sp_SetProperty / sp_OAGetProperty
procedures. This is the "non-easy" way that I thought when I wrote the
first message.
Razvan|||Thanks Razvan
I never knew about OLE prog. using T-SQL.
See the scenario is previously we used the SQL-DMO to report on SQL
Servers.
Now with Yukon coming into picture and SQL-DMO not fully compatible with
Yukon. I have to change the implementation to ADO. I can't use SMO bcoz
there is some code which is already written in ADO so I want reuse that, so
I was thinking of getting these values from the tables/system tables/views
anything but DMO and SMO. So, I'm hunting for description other
values I got throught the sysconfigures, syscurconfigs, spt_values, only
description I couldn't get.
I'm stuck only bcoz of this field.
Thanks
Pra
"Razvan Socol" <rsocol@.gmail.com> wrote in message
news:1140007841.077219.207640@.g44g2000cwa.googlegroups.com...
> Hi, Pra
> Please tell me the reason why you can't do that, so I can think of
> another way that works (not another way that you can't do, either). You
> can also state the overall scenario of what you are trying to do with
> the description and why you need this description instead of the
> description from the sys.configurations table.
> In the mean time, I would say that you can invoke the SQL-DMO code from
> T-SQL using the sp_OACreate / sp_SetProperty / sp_OAGetProperty
> procedures. This is the "non-easy" way that I thought when I wrote the
> first message.
> Razvan
>|||Hi, Pra
What do you mean by "SQL-DMO not fully compatible with Yukon" ? As far
as I know, everything that you can do using SQL-DMO against a SQL
Server 2000 server, you can also do using SQL-DMO against a SQL Server
2005 server, as long as the updated SQL-DMO components are installed
(by default they are not).
If you need to use the new features of SQL Server 2005, you should use
SMO instead of SQL-DMO (especially if you are writing a .Net
application). SMO supports SQL Server 2000, too.
If you really don't want to use SQL-DMO or SMO, you can store the
descriptions in your application: retrieve them using SQL-DMO (only
once, using a separate little app) then store them as constants (or
something else) in your code.
Razvan|||Thanks Razvan
"Razvan Socol" <rsocol@.gmail.com> wrote in message
news:1140015110.381400.268180@.g43g2000cwa.googlegroups.com...
> Hi, Pra
> What do you mean by "SQL-DMO not fully compatible with Yukon" ? As far
> as I know, everything that you can do using SQL-DMO against a SQL
> Server 2000 server, you can also do using SQL-DMO against a SQL Server
> 2005 server, as long as the updated SQL-DMO components are installed
> (by default they are not).
> If you need to use the new features of SQL Server 2005, you should use
> SMO instead of SQL-DMO (especially if you are writing a .Net
> application). SMO supports SQL Server 2000, too.
> If you really don't want to use SQL-DMO or SMO, you can store the
> descriptions in your application: retrieve them using SQL-DMO (only
> once, using a separate little app) then store them as constants (or
> something else) in your code.
> Razvan
>

No comments:

Post a Comment