Hi,
Is there any way to formulate an entire XQuery (XPath) string as a
variable and then pass it to a XQuery e.g.
Use something like this:
@.Path nvarchar(4000)
set @.Path='//category[@.name="RTE"]//sku'
SELECT AllSKUs.value('./@.name','nvarchar(MAX)') AS SKU
FROM Hierarchy CROSS APPLY
HierarchyXML.nodes(@.Path) AS NewTable(AllSKUs)
To achieve something like this:
SELECT AllSKUs.value('./@.name','nvarchar(MAX)') AS SKU
FROM Hierarchy CROSS APPLY
HierarchyXML.nodes('//category[@.name="RTE"]//sku') AS NewTable(AllSKUs)
Cheers,
Bob
Hello Bob,
No, not really because the XQuery parser is one-pass, so something like this:
declare @.x xml
set @.x = '<v>3</v>'
declare @.q varchar(255)
set @.q = '(/v)[1]'
select @.x.value('sql:variable("@.q")','int')
go
assumes that that query in @.q is meant to be a literal value so it doens't
get eval'ed as a query.
Cheers,
Kent Tegels
DevelopMentor
http://staff.develop.com/ktegels/
|||Thanks Kent,
That's a shame really - the power of XPath is not fully realised there.
I think I'll try writing the whole stored procedure dynamically.
Bob
Kent Tegels wrote:
> Hello Bob,
> No, not really because the XQuery parser is one-pass, so something like
> this:
> declare @.x xml
> set @.x = '<v>3</v>'
> declare @.q varchar(255)
> set @.q = '(/v)[1]'
> select @.x.value('sql:variable("@.q")','int')
> go
> assumes that that query in @.q is meant to be a literal value so it
> doens't get eval'ed as a query.
> Cheers,
> Kent Tegels
> DevelopMentor
> http://staff.develop.com/ktegels/
>
|||Hi Bob,
> That's a shame really - the power of XPath is not fully realised
> there. I think I'll try writing the whole stored procedure
> dynamically.
I don't know if I'd agree with that. I would say that the team has done the
best they could with limited resources, variable targets and a slower than
expected standards process. Could they have done more? Sure -- if they had
more people and time. They didn't. So I look at as glass half full. Afterall,
we're much futher along the XQuery path than the client (.NET folks are)
period.
And as I look it, I think we're only going to get limited improvements in
this support over time as Microsoft seems much more interested in putting
their resources into LINQ instead of XQuery. I'm okay with that because it
solves the problem (at least eventually), but part of me is sad to seem go
this way instead of fully investing in both.
Time will tell...
Thank you,
Kent Tegels
DevelopMentor
http://staff.develop.com/ktegels/
|||It is a shame - but what we've got now is still a huge leap ahead of
what we had before. And it's, in general, a joy to work with.
Thanks again,
Bob
Kent Tegels wrote:
> Hi Bob,
>
> I don't know if I'd agree with that. I would say that the team has done
> the best they could with limited resources, variable targets and a
> slower than expected standards process. Could they have done more? Sure
> -- if they had more people and time. They didn't. So I look at as glass
> half full. Afterall, we're much futher along the XQuery path than the
> client (.NET folks are) period.
> And as I look it, I think we're only going to get limited improvements
> in this support over time as Microsoft seems much more interested in
> putting their resources into LINQ instead of XQuery. I'm okay with that
> because it solves the problem (at least eventually), but part of me is
> sad to seem go this way instead of fully investing in both.
> Time will tell...
> Thank you,
> Kent Tegels
> DevelopMentor
> http://staff.develop.com/ktegels/
>
|||Hi Bob
Thanks for the comment ;)
We are aware of the request to not having to write dynamic SQL to provide
the XPath expression as a string variable to the XQuery methods.
I would like to encourage you to either file (or if already filed vote) such
a request at
http://lab.msdn.microsoft.com/productfeedback/
On the server we are still investing in XQuery, but as Kent mentions, many
competing requests for the same resources will have to be influenced by you
the customer requesting us to help you improve.
Thanks
Michael
"Bob Turner" <b_turner@.hotmail.co.uk> wrote in message
news:DhCTf.77298$zk4.16164@.fe3.news.blueyonder.co. uk...[vbcol=seagreen]
> It is a shame - but what we've got now is still a huge leap ahead of what
> we had before. And it's, in general, a joy to work with.
> Thanks again,
> Bob
> Kent Tegels wrote:
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment