Tuesday, March 20, 2012
BUG: Index Lost Extended Properties?
As title, i lost the extended properties when
i changed indexed collumns!
If i just change other index property such as
"unique", the extended properties is not lose.
I think it is a bug of SQL Server Management Studio.
Green Xiar
You can report bugs at http://connect.microsoft.com/sql. Make sure you include a repro and have
version number.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"greenxiar" <greenxiar@.hotmail.com> wrote in message news:OM7qlSBtHHA.2752@.TK2MSFTNGP06.phx.gbl...
> Hi
> As title, i lost the extended properties when
> i changed indexed collumns!
> If i just change other index property such as
> "unique", the extended properties is not lose.
> I think it is a bug of SQL Server Management Studio.
> Green Xiar
>
BUG: Index Lost Extended Properties?
As title, i lost the extended properties when
i changed indexed collumns!
If i just change other index property such as
"unique", the extended properties is not lose.
I think it is a bug of SQL Server Management Studio.
Green Xiar
You can report bugs at http://connect.microsoft.com/sql. Make sure you include a repro and have
version number.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"greenxiar" <greenxiar@.hotmail.com> wrote in message news:OM7qlSBtHHA.2752@.TK2MSFTNGP06.phx.gbl...
> Hi
> As title, i lost the extended properties when
> i changed indexed collumns!
> If i just change other index property such as
> "unique", the extended properties is not lose.
> I think it is a bug of SQL Server Management Studio.
> Green Xiar
>
sql
BUG: Index Lost Extended Properties?
As title, i lost the extended properties when
i changed indexed collumns!
If i just change other index property such as
"unique", the extended properties is not lose.
I think it is a bug of SQL Server Management Studio.
Green XiarYou can report bugs at http://connect.microsoft.com/sql. Make sure you include a repro and have
version number.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"greenxiar" <greenxiar@.hotmail.com> wrote in message news:OM7qlSBtHHA.2752@.TK2MSFTNGP06.phx.gbl...
> Hi
> As title, i lost the extended properties when
> i changed indexed collumns!
> If i just change other index property such as
> "unique", the extended properties is not lose.
> I think it is a bug of SQL Server Management Studio.
> Green Xiar
>
BUG: Height property reverts to inches
My system is set to UK regional settings which includes metric measurements.
When I add section to a report, i.e Header or Footer the height property is in inches.
If I change the height, say to 2 it correctly treats it as centimetres. A small oversight me thinks!
Regards
Chris McGuiganYou are correct. Thanks for catching this one.
--
Bruce Johnson [MSFT]
Microsoft SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"Chris McGuigan" <ChrisMcGuigan@.discussions.microsoft.com> wrote in message
news:A45D03E9-4B69-4FB9-B056-8B9A8683E23F@.microsoft.com...
> Just thought I'd report a little bug I'd found.
> My system is set to UK regional settings which includes metric
measurements.
> When I add section to a report, i.e Header or Footer the height property
is in inches.
> If I change the height, say to 2 it correctly treats it as centimetres. A
small oversight me thinks!
> Regards
> Chris McGuigan
Bug: Expression on Disable property doesn''t have desired effect
[Microsoft follow-up]
Hello,
I think I've found a bug.
I have an expression set on the 'Disable' property of a data-flow task. When the expression evaluates to true the data-flow still executes. That seems wrong to me.
I ahve a demo package here: http://folders.live.com/self.aspx/VQ9oHa1TJjc/Public/SSIS%20Stuff/ExamplePackages/20070717%20Expression%20on%20Disable%20property%20has%20no%20effect/Package1.zip
Please reply letting me know whether this is indeed a bug or not.
I'm on SP1 by the way.
Regards
Jamie
Seems to me that the tasks need to know if they are going to be executed or not before variable expressions are enforced.
SP2 has this behavior though -- just an FYI
|||
Phil Brammer wrote:
Seems to me that the tasks need to know if they are going to be executed or not before variable expressions are enforced.
SP2 has this behavior though -- just an FYI
Well that's not intuitive at all. And it also wouldn't explain why this: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=465533&SiteID=1 would work.
Hopefully someone from the SSIS team replies ASAP.
-Jamie
|||The following configuration will disable the data flow, using your example.
Code Snippet
<?xml version="1.0"?>
<DTSConfiguration>
<DTSConfigurationHeading>
<DTSConfigurationFileInfo GeneratedBy="CT\jtbx" GeneratedFromPackageName="DisableProperty" GeneratedFromPackageID="{DDA8184A-42AF-414A-B01C-CB3FCCB8988D}" GeneratedDate="7/17/2007 7:50:43 PM"/>
</DTSConfigurationHeading>
<Configuration ConfiguredType="Property" Path="\Package.Variables[User::Variable].Properties[Value]" ValueType="Int32">
<ConfiguredValue>1</ConfiguredValue>
</Configuration>
</DTSConfiguration>
The reason for use of package configuration(s) over a script task is that a container's Disable property is evaluated at package load time, not at package execution time..
Since package configuration occurs at load time, configuration of properties will affect the container's Disable property, either directly or via an expression, while the script task sets the expression-participating variable at execution time, and is thus too late.
Also note that Donald Farmer's bitmask solution uses a a configuration as well, and thus may change the container's Disable property, for the very same reason.
|||
jaegd wrote:
The reason for use of package configuration(s) over a script task is that a container's Disable property is evaluated at package load time, not at package execution time..
If that's true then I'd like to understand the rationale behind it because that behaviour is totally different from any other container property.
jaegd wrote:
Also note that Donald Farmer's bitmask solution uses a a configuration as well, and thus may change the container's Disable property, for the very same reason.
It uses a configuration to set the value but that is irrelevant in the context of this thread. I'm talking about how an expression on the Disable property is not being evaluated properly.
Thanks for the reply jaegd but I still want a response from Microsoft.
-Jamie
|||I will take a look and return with an answer soon.
Thanks,
Ovidiu Burlacu - MSFT
|||
Ovidiu Burlacu wrote:
I will take a look and return with an answer soon.
Thanks,
Ovidiu Burlacu - MSFT
Thanks Ovidiu. I look forward to the reply.
Hi Jamie,
I looked at your repro and this is indeed a bug. Can you please open a bug? (or I can open one)
Thanks,
Ovidiu
|||
Ovidiu Burlacu wrote:
Hi Jamie,
I looked at your repro and this is indeed a bug. Can you please open a bug? (or I can open one)
Thanks,
Ovidiu
From Jamie Thomson:
[I've asked Phil to post this for me as I am currently locked out of the forums due to some bug]
Thanks Ovidiu. I have posted the bug here: https://connect.microsoft.com Interestingly, I found out that this has been raised before back in 2005 (https://connect.microsoft.com - Jamie
Bug: Expression on Disable property doesn't have desired effect
[Microsoft follow-up]
Hello,
I think I've found a bug.
I have an expression set on the 'Disable' property of a data-flow task. When the expression evaluates to true the data-flow still executes. That seems wrong to me.
I ahve a demo package here: http://folders.live.com/self.aspx/VQ9oHa1TJjc/Public/SSIS%20Stuff/ExamplePackages/20070717%20Expression%20on%20Disable%20property%20has%20no%20effect/Package1.zip
Please reply letting me know whether this is indeed a bug or not.
I'm on SP1 by the way.
Regards
Jamie
Seems to me that the tasks need to know if they are going to be executed or not before variable expressions are enforced.
SP2 has this behavior though -- just an FYI
|||
Phil Brammer wrote:
Seems to me that the tasks need to know if they are going to be executed or not before variable expressions are enforced.
SP2 has this behavior though -- just an FYI
Well that's not intuitive at all. And it also wouldn't explain why this: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=465533&SiteID=1 would work.
Hopefully someone from the SSIS team replies ASAP.
-Jamie
|||The following configuration will disable the data flow, using your example.
Code Snippet
<?xml version="1.0"?>
<DTSConfiguration>
<DTSConfigurationHeading>
<DTSConfigurationFileInfo GeneratedBy="CT\jtbx" GeneratedFromPackageName="DisableProperty" GeneratedFromPackageID="{DDA8184A-42AF-414A-B01C-CB3FCCB8988D}" GeneratedDate="7/17/2007 7:50:43 PM"/>
</DTSConfigurationHeading>
<Configuration ConfiguredType="Property" Path="\Package.Variables[User::Variable].Properties[Value]" ValueType="Int32">
<ConfiguredValue>1</ConfiguredValue>
</Configuration>
</DTSConfiguration>
The reason for use of package configuration(s) over a script task is that a container's Disable property is evaluated at package load time, not at package execution time..
Since package configuration occurs at load time, configuration of properties will affect the container's Disable property, either directly or via an expression, while the script task sets the expression-participating variable at execution time, and is thus too late.
Also note that Donald Farmer's bitmask solution uses a a configuration as well, and thus may change the container's Disable property, for the very same reason.
|||
jaegd wrote:
The reason for use of package configuration(s) over a script task is that a container's Disable property is evaluated at package load time, not at package execution time..
If that's true then I'd like to understand the rationale behind it because that behaviour is totally different from any other container property.
jaegd wrote:
Also note that Donald Farmer's bitmask solution uses a a configuration as well, and thus may change the container's Disable property, for the very same reason.
It uses a configuration to set the value but that is irrelevant in the context of this thread. I'm talking about how an expression on the Disable property is not being evaluated properly.
Thanks for the reply jaegd but I still want a response from Microsoft.
-Jamie
|||I will take a look and return with an answer soon.
Thanks,
Ovidiu Burlacu - MSFT
|||
Ovidiu Burlacu wrote:
I will take a look and return with an answer soon.
Thanks,
Ovidiu Burlacu - MSFT
Thanks Ovidiu. I look forward to the reply.
Hi Jamie,
I looked at your repro and this is indeed a bug. Can you please open a bug? (or I can open one)
Thanks,
Ovidiu
|||
Ovidiu Burlacu wrote:
Hi Jamie,
I looked at your repro and this is indeed a bug. Can you please open a bug? (or I can open one)
Thanks,
Ovidiu
From Jamie Thomson:
[I've asked Phil to post this for me as I am currently locked out of the forums due to some bug]
Thanks Ovidiu. I have posted the bug here: https://connect.microsoft.com Interestingly, I found out that this has been raised before back in 2005 (https://connect.microsoft.com - Jamiesql
Sunday, February 19, 2012
Broadcast existence of SQL Server
Does anyone know where to find the property that disables the broadcast of the sql server from the point where you do not see the server show up in the list when one goes to
"New SQL Server Registration" -> "..."
beside the "Server" field. The dialog itself is titled "Registered SQL Server Properties". Assume both SQL Servers are both behind the firewall.While it isn't 100%, you can get a good start by disabling the Named Pipes Broadcast (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adminsql/ad_security_97cb.asp) for SQL Server.
-PatP|||Thanks for the reg key option. For some reason I seemed to remember seeing an option where you can set this from the enterprise UI. I could be wrong but does anyone remember anything along those lines.|||Thanks for the reg key option. For some reason I seemed to remember seeing an option where you can set this from the enterprise UI. I could be wrong but does anyone remember anything along those lines.
Start->Programs->SQL Server->Server Network Utility; in the General Tab, select TCPIP. Select Properties, Check the option HIDE SERVER.
it would force SQL stop broad casting the port it's listening to.|||Start->Programs->SQL Server->Server Network Utility; in the General Tab, select TCPIP. Select Properties, Check the option HIDE SERVER.
it would force SQL stop broad casting the port it's listening to.I think that is only a choice for named instances of SQL Server.
-PatP|||I think that is only a choice for named instances of SQL Server.
-PatP
Hi. This is what BOL says.
[Hide server
Select to hide the instance of Microsoft SQL Server. When you hide an instance of SQL Server, responses to broadcasts from clients attempting to enumerate those instances of SQL Server present on the network are disabled.]
named instance is not exclusively mentioned; have to test the scenario