Search

SSDT Fails to deploy XPath case sensitive fixes by Jeff Fischer

Closed
as Won't Fix Help for as Won't Fix

2
0
Sign in
to vote
Type: Bug
ID: 778893
Opened: 2/9/2013 10:33:34 PM
Access Restriction: Public
0
Workaround(s)
0
User(s) can reproduce this bug
SSDT SqlPackage.exe does not recognize case sensitive updates. Therefore, it fails to deploy case-only xpath updates to scripts.
Details (expand)

Product Language

English

Version

SQL Server 2012 - Express Edition

Category

Data-Tier Application Framework (Dac, DacFX, DACPAC)

Operating System

Windows Server 2008 (all editions)

Operating System Language

US English

Steps to Reproduce

Create and deploy the following stored procedure within an SSDT project.

CREATE PROC dbo.TestXPath
As
    DECLARE @TestXml xml = '<Test><Case><Sensitive>Yes</Sensitive></Case></Test>'
    
    SELECT @TestXml.value('(/Test/Case/sensitive)[1]', 'nvarchar(100)')
GO

Execute the proc and notice NULL result. Fix the casing of the Sensitive element in the xpath expression. Redeploy and re-execute. Notice the NULL results still.

Actual Results

Necessary case-only updates within SSDT projects are not deployed when case is the only update made.

Expected Results

All updates no matter whether case only or not should be deployed independent of whether the SQL Server is set to be case sensitive or case insensitive.

Platform

X64

Virtualization

 
File Attachments
0 attachments
Sign in to post a comment.
Posted by Jeff Fischer on 2/15/2013 at 10:58 PM
As you know, that's a useless workaround.
Posted by Microsoft on 2/15/2013 at 8:00 AM
Hey Jeff,

Thanks for the feedback around the case sensitivity of the XPath expressions used in the .value functions in stored procedure bodies. The root cause of this issue is the way we represent stored procedure bodies and compare them using the target db collation. We are not appropriately recognizing the implicit need to be case sensitive inside this part of the proc body.

Unfortunately, due to the priorities of other issues, the team will not be pursuing a fix for this issue. The workaround is to use a case sensitive collation on the target database which will then be used to compare the body of the procedure.

Thanks and please let us know if you have any additional questions,
Adam Mahood
Program Manager
SQL Server Database Systems
Sign in to post a workaround.