orphaned extended properties in SQL

Question

orphaned extended properties in SQL

jasonclements32304

Ten Centuries

Points: 1122
More actions
January 15, 2013 at 7:59 am

#268718

Is it possible to have orphaned extended properties in SQL.
And if so what is best practice to clean them up?
And how are they caused?

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply

Lowell SSC Guru Points: 323518 More actions · Answer 1

it depends;

you cannot create an extended property that points to an object(includes the parameters for level0type/@level1type/@level2type) without the object actually existing.

an example:

EXEC sys.sp_addextendedproperty

@name=N'ColumnDescription',

@value=N'Credit Card Expiration Date' ,

@level0type=N'SCHEMA',

@level0name=N'dbo',

@level1type=N'TABLE',

@level1name=N'CustomerOrder',

@level2type=N'COLUMN',

@level2name=N'Order_CCExp'

Msg 15135, Level 16, State 8, Procedure sp_addextendedproperty, Line 37
Object is invalid. Extended properties are not permitted on 'dbo.CustomerOrder.Order_CCExp', or the object does not exist.

if you delete the object, the extended properties for that object get deleted too.

CREATE procedure [dbo].[sp_find]

@findcolumn varchar(50)

as

begin

set nocount on

select sysobjects.name as TableFound,syscolumns.name as ColumnFound

from sysobjects

inner join syscolumns on sysobjects.id=syscolumns.id

where sysobjects.xtype='U'

and (syscolumns.name like '%' + @findcolumn +'%'

or sysobjects.name like '%' + @findcolumn +'%' )

order by TableFound,ColumnFound

end

GO

EXEC sys.sp_addextendedproperty

@name = N'Version',

@value = N'9.0.154.90',

@level0type = N'SCHEMA', @level0name = 'dbo',

@level1type = N'PROCEDURE', @level1name = 'sp_find';

EXEC sys.sp_addextendedproperty

@name = N'Purpose',

@value = N'simple tool to find column or table names that are LIKE the inputed value',

@level0type = N'SCHEMA', @level0name = 'dbo',

@level1type = N'PROCEDURE', @level1name = 'sp_find';

--show all extended properties

SELECT objtype, objname, name, value

FROM fn_listextendedproperty (NULL, 'schema', 'dbo', 'PROCEDURE', 'sp_find', NULL, NULL);

--get just the "Version" that i created:

SELECT objtype, objname, name, value

FROM fn_listextendedproperty ('Version', 'schema', 'dbo', 'PROCEDURE', 'sp_find', NULL, NULL);

you can create extended property nave/value pairs that are not connected to anything, so i wouldn't call them stranded, but they might not make sense to someone.

EXEC sys.sp_addextendedproperty

@name = N'Version',

@value = N'9.0.154.90'

EXEC sys.sp_addextendedproperty

@name = N'InstanceName',

@value = N'LOWELL\SQL2008'

Lowell

--help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

ScottPletcher SSC Guru Points: 101097 More actions · Answer 2

As Lowell states, they're not really orphaned.

Extended properties that aren't explicitly subordinated to a db object apply to the db itself.

That is, if you add extended properties w/o specifying a specific object, they become extended properties of the db itself, so only dropping the db would drop those extended properties.

Otoh, if you add extended properties to a column, for example, they "belong" to that column and automatically get dropped with the column (or owning table) itself.

SQL DBA,SQL Server MVP(07, 08, 09) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".

Dwain Camps SSC Guru Points: 86948 More actions · Answer 3

Another cool thing about extended properties is that, when you add them (for example) to a table or to a column, when you use SSMS to script that table's creation, the script includes adding the current extended properties. So they are easily transferred between databases.

Does anyone besides me find it irritating that you have to know whether a property exists or not and then either add it or insert it? You'd think the system maintenance SPs could be made smart enough to handle this case.

My mantra: No loops! No CURSORs! No RBAR! Hoo-uh![/I]
My thought question: Have you ever been told that your query runs too fast?

My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.

Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St

jasonclements32304 Ten Centuries Points: 1122 More actions · Answer 4

Thanks for all the great replies. I'm learning alot.

I was working on reviewing extended properties we currently have and forgot to join to sys.objects. I was joined to sys.table. So I thought I was looking at orphans. Brain Fart!

Me and my team are using Red-gate's SQLDOC for our DB Docs. We have a built nightly PowerShell that run SQLDOC command line that is running to over the current post SQLDOCs.

<#

=====================

Delete Current SQLDOC

=====================

#>

$path = '\\server\d$\PVP\PVP21\webcontent\Powershell\Database_Documentation\DBPrime1\'

Get-ChildItem $path |

Sort-Object { $_.Name -as [Version] } |

Select-Object -Last 1 |

Remove-Item -recurse

<#

===============

Create SQLDOC

===============

#>

$CMD = 'C:\Program Files (x86)\Red Gate\SQL Doc 2\sqldoc.exe'

$arg1 = '/project:H:\My Documents\SQL Server Management Studio\Red-Gate\DBPrime1.sqldoc'

$arg2 = '/filetype:html-frames'

$arg3 = '/force'

$arg4 = '/outputfolder:"\\server\d$\PVP\PVP21\webcontent\Powershell\Database_Documentation\DBPrime1"'

& $CMD $arg1 $arg2 $arg3 $arg4

<#

"C:\Program Files (x86)\Red Gate\SQL Doc 2\sqldoc.exe" /project:"H:\My Documents\SQL Server Management Studio\Red-Gate\DBPrime1.sqldoc" /filetype:html-frames /force /outputfolder:"\\rpt102\d$\PVP\PVP21\webcontent\Powershell\Database_Documentation\DBPrime1"

#>

<#

===============

Rename Directory

===============

#>

cd \\server\d$\PVP\PVP21\webcontent\Powershell\Database_Documentation\DBPrime1

dir | Where-Object {$_.Name} | Rename-Item -NewName "DBPrime1"

I have created a have also created a SSMSToolPack Custom Script. That we can run to create our custom extended properties when we are developing the tables, views, SP, and etc.

DECLARE @type varchar(50), @timestamp DATETIME, @user VARCHAR(100)

SELECT @type=CASE WHEN [type] = 'U'

THEN 'TABLE'

WHEN [type] = 'V'

THEN'VIEW'

WHEN [type] = 'P'

THEN 'PROCEDURE

WHEN [type] = 'PK'

THEN 'PRIMARY_KEY_CONSTRAINT'

WHEN [TYPE] = 'D'

THEN 'DEFAULT_CONSTRAINT'

WHEN [type] = 'FN'

THEN 'SQL_SCALAR_FUNCTION'

END

FROM sys.objects

WHERE [NAME] = '|ObjectName|'

SELECT @timestamp=GETDATE()

SELECT @user=SYSTEM_USER

EXEC sys.sp_addextendedproperty @name=N'Created by', @value=@user , @level0type=N'SCHEMA',@level0name=N'dbo', @level1type=@type,@level1name=N'|ObjectName|'

EXEC sys.sp_addextendedproperty @name=N'Purpose', @value=N'' , @level0type=N'SCHEMA',@level0name=N'dbo', @level1type=@type,@level1name=N'|ObjectName|'

EXEC sys.sp_addextendedproperty @name=N'Created on', @value=@timestamp, @level0type=N'SCHEMA',@level0name=N'dbo', @level1type=@type,@level1name=N'|ObjectName|'

GO

My new thought was this morning is it even possible to have default extended properties when the tables or etc. are created? Default extended properties. Standards for all users to fill in.

jasonclements32304 Ten Centuries Points: 1122 More actions · Answer 5

Answered my own question today.

I setup a new Database trigger:

CREATE TRIGGER [DB_Add_extended_propeties]

ON DATABASE

FOR CREATE_TABLE,CREATE_VIEW, CREATE_PROCEDURE

AS

SET NOCOUNT ON

DECLARE @eventInfo XML

SET @eventInfo = EVENTDATA()

DECLARE @timestamp DATETIME, @user VARCHAR(100), @ObjectType VARCHAR(50), @ObjectName VARCHAR(50)

SELECT @timestamp=GETDATE()

SELECT @user=SYSTEM_USER

SET @ObjectType=CONVERT(VARCHAR(50),@eventInfo.query('data(/EVENT_INSTANCE/ObjectType)'))

SET @ObjectName=CONVERT(VARCHAR(50),@eventInfo.query('data(/EVENT_INSTANCE/ObjectName)'))

EXEC sys.sp_addextendedproperty @name=N'Created by', @value=@user , @level0type=N'SCHEMA',@level0name=N'dbo', @level1type=@ObjectType ,@level1name=@ObjectName

EXEC sys.sp_addextendedproperty @name=N'Purpose', @value=N'' , @level0type=N'SCHEMA',@level0name=N'dbo', @level1type=@ObjectType ,@level1name=@ObjectName

EXEC sys.sp_addextendedproperty @name=N'Created on', @value=@timestamp, @level0type=N'SCHEMA',@level0name=N'dbo', @level1type=@ObjectType ,@level1name=@ObjectName

GO