Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Gäller för:SQL Server
W3C-specifikationen gör att typfel kan utlösas statiskt eller dynamiskt och definierar statiska, dynamiska fel och typfel.
Kompilering och felhantering
Kompileringsfel returneras från syntaktiskt felaktiga Xquery-uttryck och XML DML -instruktioner. Kompileringsfasen kontrollerar att XQuery-uttryck och DML-uttryck är statiska och använder XML-scheman för typinferenser för typinferenser för typinmatning av XML. Det ger upphov till statiska typfel om ett uttryck kan misslyckas vid körning på grund av en typ av säkerhetsöverträdelse. Exempel på statiska fel är att lägga till en sträng i ett heltal och fråga efter en nod som inte finns för inskrivna data.
Som en avvikelse från W3C-standarden konverteras XQuery-körningsfel till tomma sekvenser. Dessa sekvenser kan spridas som tom XML eller NULL till frågeresultatet, beroende på anropskontexten.
Explicit gjutning till rätt typ gör att användarna kan kringgå statiska fel, även om körningsfel omvandlas till tomma sekvenser.
Anmärkning
Parsningsfel som utlöses av XQuery-parsern (till exempel syntaxfel i XML som refereras som en del av XML-datatypsmetoden, till exempel), avbryter den aktiva transaktionen, oavsett inställningen XACT_ABORT för den aktuella sessionen.
Statiska fel
Statiska fel returneras med hjälp av felmekanismen Transact-SQL. I SQL Server returneras XQuery-typfel statiskt. Mer information finns i XQuery och Static Typing.
Dynamiska fel
I XQuery mappas de flesta dynamiska felen till en tom sekvens ("()"). Det här är dock de två undantagen: Overflow-villkor i XQuery-sammansättningsfunktioner och XML-DML valideringsfel. De flesta dynamiska fel mappas till en tom sekvens. Annars kan frågekörning som drar nytta av XML-index generera oväntade fel. För att tillhandahålla en effektiv körning utan att generera oväntade fel mappar SQL Server Database Engine därför dynamiska fel till ().
Ofta, i den situation där det dynamiska felet skulle inträffa i ett predikat, ändrar inte höjningen av felet semantiken eftersom () mappas till False. Men i vissa fall kan det leda till oväntade resultat om du returnerar () i stället för ett dynamiskt fel. Följande är exempel som illustrerar detta.
Exempel: Använda funktionen avg() med en sträng
I följande exempel anropas funktionen Avg för att beräkna medelvärdet av de tre värdena. Ett av dessa värden är en sträng. Eftersom XML-instansen i det här fallet är otypad är alla data i den av otypad atomisk typ. Funktionen avg() omvandlar först dessa värden till xs:double innan medelvärdet beräknas. Värdet "Hello", , kan dock inte omvandlas till xs:double och skapar ett dynamiskt fel. I det här fallet, i stället för att returnera ett dynamiskt fel, orsakar gjutningen av "Hello" till xs:double en tom sekvens. Funktionen avg() ignorerar det här värdet, beräknar medelvärdet av de andra två värdena och returnerar 150.
DECLARE @x xml
SET @x=N'<root xmlns:myNS="test">
<a>100</a>
<b>200</b>
<c>Hello</c>
</root>'
SELECT @x.query('avg(//*)')
Exempel: Använda funktionen inte
När du använder funktionen Inte i ett predikat, /SomeNode[not(Expression)]till exempel , och uttrycket orsakar ett dynamiskt fel, returneras en tom sekvens i stället för ett fel. Om not() tillämpas på den tomma sekvensen returneras Sant, i stället för ett fel.
Exempel: Gjuta en sträng
I följande exempel omvandlas den literala strängen "NaN" till xs:string och sedan till xs:double. Resultatet är en tom raduppsättning. Även om strängen "NaN" inte kan gjutas till xs:double kan detta inte fastställas förrän körningen eftersom strängen först omvandlas till xs:string.
DECLARE @x XML
SET @x = ''
SELECT @x.query(' xs:double(xs:string("NaN")) ')
GO
I det här exemplet uppstår dock ett statiskt typfel.
DECLARE @x XML
SET @x = ''
SELECT @x.query(' xs:double("NaN") ')
GO
Implementeringsbegränsningar
Funktionen fn:error() stöds inte.