Changing Server Name

I change the server name where SQL was original installed but the result of
'select @.@.servername' is still returning the name of the original server. Hod
dow I correct this?
Thanks
check out sp_addserver in BOL. That should help you.
"Emma" <Emma@.discussions.microsoft.com> wrote in message
news:362A7AD0-8C08-4BB7-B27C-4B9F4B3E1F3F@.microsoft.com...
> I change the server name where SQL was original installed but the result
of
> 'select @.@.servername' is still returning the name of the original server.
Hod
> dow I correct this?
> Thanks
|||Do:
EXEC sp_dropserver 'oldname'
GO
EXEC sp_addserver 'newname', 'local', null
GO
Restart the server & @.@.SERVERNAME should return 'newname'. See the topic
"Renaming a Server" in SQL Server Books Online.
Anith

Changing Server Name

I change the server name where SQL was original installed but the result of
'select @.@.servername' is still returning the name of the original server. Hod
dow I correct this?
Thankscheck out sp_addserver in BOL. That should help you.
"Emma" <Emma@.discussions.microsoft.com> wrote in message
news:362A7AD0-8C08-4BB7-B27C-4B9F4B3E1F3F@.microsoft.com...
> I change the server name where SQL was original installed but the result
of
> 'select @.@.servername' is still returning the name of the original server.
Hod
> dow I correct this?
> Thanks|||Do:
EXEC sp_dropserver 'oldname'
GO
EXEC sp_addserver 'newname', 'local', null
GO
Restart the server & @.@.SERVERNAME should return 'newname'. See the topic
"Renaming a Server" in SQL Server Books Online.
--
Anith

Changing Server Name

I change the server name where SQL was original installed but the result of
'select @.@.servername' is still returning the name of the original server. Ho
d
dow I correct this?
Thankscheck out sp_addserver in BOL. That should help you.
"Emma" <Emma@.discussions.microsoft.com> wrote in message
news:362A7AD0-8C08-4BB7-B27C-4B9F4B3E1F3F@.microsoft.com...
> I change the server name where SQL was original installed but the result
of
> 'select @.@.servername' is still returning the name of the original server.
Hod
> dow I correct this?
> Thanks|||Do:
EXEC sp_dropserver 'oldname'
GO
EXEC sp_addserver 'newname', 'local', null
GO
Restart the server & @.@.SERVERNAME should return 'newname'. See the topic
"Renaming a Server" in SQL Server Books Online.
Anith

Changing label of y-axis

For my report i have to change the label of the y-axis. My dataset is
returning integer values "0", "1", "2". These values are now shown as the
label. However, i need to translate these ID's to string values, such as "0"
= "no value available", "1" = "service down", "2" = "service up".
I have tied to insert a code snippet for conditinal names in the Label
Format Code field
=IIF(Fields!Parameter.Value=0, "no values available", Fields!Parameter.Value)
but this does not solve the problem, because it seems i can only use
formatting code in the label field.
Is there a way to do this or do i have to label my y-axis as is and insert a
legend to let the reader of the report know, what that values are meaning?For the series or category (I forget which one is the y-axis), specify the
following instead of just "Fields!myvalue.value"
=IIF(Fields!myValue.value = 0, "No value available",
IIF(Fields!myValue.Value = 1, "Service Down", "Service Up"))
Replace "myvalue" with the actual name of your column.
"Ben" <yogiben_at_gmx_dot_net> wrote in message
news:2B86E61F-186C-4A74-AE0B-EAF85F1DF9C7@.microsoft.com...
> For my report i have to change the label of the y-axis. My dataset is
> returning integer values "0", "1", "2". These values are now shown as the
> label. However, i need to translate these ID's to string values, such as
> "0"
> = "no value available", "1" = "service down", "2" = "service up".
> I have tied to insert a code snippet for conditinal names in the Label
> Format Code field
> =IIF(Fields!Parameter.Value=0, "no values available",
> Fields!Parameter.Value)
> but this does not solve the problem, because it seems i can only use
> formatting code in the label field.
> Is there a way to do this or do i have to label my y-axis as is and insert
> a
> legend to let the reader of the report know, what that values are meaning?

Changing Explain Plan

Hi,
We have a stored proc that generally returns in about 4-5 seconds. Over the
course of a few days (2-5) the stored proc starts returning in about 50 sec
onds. The change is sudden, not a gradual degradation. The explain plan ha
s changed. If I then add a
hint to the main query (loop join), compile it, take the hint back out, comp
ile it (ie it is now exactly the same as it was), it then starts returning i
n 4-5 seconds once again.
We have automatic creation and update of statisics turned on. The profile o
f the data doesn't change that much day-to-day.
Why is it so? How to stop SQL Server from changing the plans for this query
?
TIA,
SJTHi SJT,
Sudden performance degrade might might be due to "Fragmetation". Can you
execute the DBCC SHOWCONTIG on all tables and identify the tables
which is fragmented. For all fragmented table you could run DBCC DBREINDEX
or DBCC INDEXDEFRAG to remove fragmetation.
See the details of DBCC SHOWCONTIG, DBCC DBREINDEX and DBCC INDEXDEFRAG in
boks online.
How to stop SQL Server from changing the plans for this query?
See "Execution Plan Caching and Reuse" in books online.
Thanks
Hari
MCDBA
"SJT" <SJT@.discussions.microsoft.com> wrote in message
news:E48CD7B7-28C0-4A13-99C7-5ED85FB7E5D8@.microsoft.com...
> Hi,
> We have a stored proc that generally returns in about 4-5 seconds. Over
the course of a few days (2-5) the stored proc starts returning in about 50
seconds. The change is sudden, not a gradual degradation. The explain plan
has changed. If I then add a hint to the main query (loop join), compile
it, take the hint back out, compile it (ie it is now exactly the same as it
was), it then starts returning in 4-5 seconds once again.
> We have automatic creation and update of statisics turned on. The profile
of the data doesn't change that much day-to-day.
> Why is it so? How to stop SQL Server from changing the plans for this
query?
> TIA,
> SJT|||SJT,
instead of rewriting the query two times, see if "sp_recompile <name of
SP>" achieves the same thing.
Also, search Google for "parameter sniffing", and see if that is causing
your procedure's peformance fluctuation.
Hope this helps,
Gert-Jan
SJT wrote:
> Hi,
> We have a stored proc that generally returns in about 4-5 seconds. Over the cours
e of a few days (2-5) the stored proc starts returning in about 50 seconds. The cha
nge is sudden, not a gradual degradation. The explain plan has changed. If I then
add
a hint to the main query (loop join), compile it, take the hint back out, compile it (ie it
is now exactly the same as it was), it then starts returning in 4-5 seconds once again.[vbco
l=seagreen]
> We have automatic creation and update of statisics turned on. The profile
of the data doesn't change that much day-to-day.
> Why is it so? How to stop SQL Server from changing the plans for this que
ry?
> TIA,
> SJT[/vbcol]
(Please reply only to the newsgroup)

Changing Explain Plan

Hi,
We have a stored proc that generally returns in about 4-5 seconds. Over the course of a few days (2-5) the stored proc starts returning in about 50 seconds. The change is sudden, not a gradual degradation. The explain plan has changed. If I then add a
hint to the main query (loop join), compile it, take the hint back out, compile it (ie it is now exactly the same as it was), it then starts returning in 4-5 seconds once again.
We have automatic creation and update of statisics turned on. The profile of the data doesn't change that much day-to-day.
Why is it so? How to stop SQL Server from changing the plans for this query?
TIA,
SJT
Hi SJT,
Sudden performance degrade might might be due to "Fragmetation". Can you
execute the DBCC SHOWCONTIG on all tables and identify the tables
which is fragmented. For all fragmented table you could run DBCC DBREINDEX
or DBCC INDEXDEFRAG to remove fragmetation.
See the details of DBCC SHOWCONTIG, DBCC DBREINDEX and DBCC INDEXDEFRAG in
boks online.
How to stop SQL Server from changing the plans for this query?
See "Execution Plan Caching and Reuse" in books online.
Thanks
Hari
MCDBA
"SJT" <SJT@.discussions.microsoft.com> wrote in message
news:E48CD7B7-28C0-4A13-99C7-5ED85FB7E5D8@.microsoft.com...
> Hi,
> We have a stored proc that generally returns in about 4-5 seconds. Over
the course of a few days (2-5) the stored proc starts returning in about 50
seconds. The change is sudden, not a gradual degradation. The explain plan
has changed. If I then add a hint to the main query (loop join), compile
it, take the hint back out, compile it (ie it is now exactly the same as it
was), it then starts returning in 4-5 seconds once again.
> We have automatic creation and update of statisics turned on. The profile
of the data doesn't change that much day-to-day.
> Why is it so? How to stop SQL Server from changing the plans for this
query?
> TIA,
> SJT
|||SJT,
instead of rewriting the query two times, see if "sp_recompile <name of
SP>" achieves the same thing.
Also, search Google for "parameter sniffing", and see if that is causing
your procedure's peformance fluctuation.
Hope this helps,
Gert-Jan
SJT wrote:
> Hi,
> We have a stored proc that generally returns in about 4-5 seconds. Over the course of a few days (2-5) the stored proc starts returning in about 50 seconds. The change is sudden, not a gradual degradation. The explain plan has changed. If I then add
a hint to the main query (loop join), compile it, take the hint back out, compile it (ie it is now exactly the same as it was), it then starts returning in 4-5 seconds once again.
> We have automatic creation and update of statisics turned on. The profile of the data doesn't change that much day-to-day.
> Why is it so? How to stop SQL Server from changing the plans for this query?
> TIA,
> SJT
(Please reply only to the newsgroup)

Changing Explain Plan

Hi,
We have a stored proc that generally returns in about 4-5 seconds. Over the course of a few days (2-5) the stored proc starts returning in about 50 seconds. The change is sudden, not a gradual degradation. The explain plan has changed. If I then add a hint to the main query (loop join), compile it, take the hint back out, compile it (ie it is now exactly the same as it was), it then starts returning in 4-5 seconds once again.
We have automatic creation and update of statisics turned on. The profile of the data doesn't change that much day-to-day.
Why is it so? How to stop SQL Server from changing the plans for this query?
TIA,
SJTHi SJT,
Sudden performance degrade might might be due to "Fragmetation". Can you
execute the DBCC SHOWCONTIG on all tables and identify the tables
which is fragmented. For all fragmented table you could run DBCC DBREINDEX
or DBCC INDEXDEFRAG to remove fragmetation.
See the details of DBCC SHOWCONTIG, DBCC DBREINDEX and DBCC INDEXDEFRAG in
boks online.
How to stop SQL Server from changing the plans for this query?
See "Execution Plan Caching and Reuse" in books online.
Thanks
Hari
MCDBA
"SJT" <SJT@.discussions.microsoft.com> wrote in message
news:E48CD7B7-28C0-4A13-99C7-5ED85FB7E5D8@.microsoft.com...
> Hi,
> We have a stored proc that generally returns in about 4-5 seconds. Over
the course of a few days (2-5) the stored proc starts returning in about 50
seconds. The change is sudden, not a gradual degradation. The explain plan
has changed. If I then add a hint to the main query (loop join), compile
it, take the hint back out, compile it (ie it is now exactly the same as it
was), it then starts returning in 4-5 seconds once again.
> We have automatic creation and update of statisics turned on. The profile
of the data doesn't change that much day-to-day.
> Why is it so? How to stop SQL Server from changing the plans for this
query?
> TIA,
> SJT|||SJT,
instead of rewriting the query two times, see if "sp_recompile <name of
SP>" achieves the same thing.
Also, search Google for "parameter sniffing", and see if that is causing
your procedure's peformance fluctuation.
Hope this helps,
Gert-Jan
SJT wrote:
> Hi,
> We have a stored proc that generally returns in about 4-5 seconds. Over the course of a few days (2-5) the stored proc starts returning in about 50 seconds. The change is sudden, not a gradual degradation. The explain plan has changed. If I then add a hint to the main query (loop join), compile it, take the hint back out, compile it (ie it is now exactly the same as it was), it then starts returning in 4-5 seconds once again.
> We have automatic creation and update of statisics turned on. The profile of the data doesn't change that much day-to-day.
> Why is it so? How to stop SQL Server from changing the plans for this query?
> TIA,
> SJT
--
(Please reply only to the newsgroup)