hi I hope I didn’t put too many questions 1) Why can’t recursive queries contain • GROUP BY, • LEFT/RIGHT JOINS • SELECT DISTINCT • AGGREGATE FUNCTIONS • SUBQUERIES • hints on the recursive CTE reference BTW - What is meant “by hints on the recursive CTE reference”? 2) Anchor queries can be unioned together with UNION operator, so why can’t recursive queries also be unioned together with ...
Hi Klem, Simple - because that are the limitation the development team chose to put in place. <speculation mode on> Allowing these options would probably allow users to write queries that were too hard to figure out how to do, or that would require more development time than was necessary. Evey option allowed adds to the complexion of the final product. Remember that if an option is allowed, ...
MS SQL Server is a minimal subset of the ANSI/ISO Standards. In Standard SQL, the WITH clause is "WITH [recursive]<cte name>" so that the compiler gets to change modes when a CTE is recursive. There are other differences. I am at speaking at PASS now and then going to SQL Connections, so I do not have my Standards with me; Google around for it. I think the Standard might allow for any set ...
It is not as restrictive as it first looks like 1. You can use subqueries but they have to be expressed as CROSS (like JOIN) or OUTER (like LEFT JOIN) APPLYs WITH bla AS ( SELECT FROM ancor UNION ALL SELECT FROM bla r CROSS APPLY -- using OUTER APPLY will be like LEFT JOIN ( SELECT FROM someotherplace t WHERE t.key = r.key )v...
You can do this too, if you need to build table of content type of output. WITH bla AS ( SELECT FROM ancor UNION ALL SELECT FROM bla r OUTER APPLY ( SELECT FROM someplace t WHERE t.key = r.key )v UNION ALL SELECT FROM bla r CROSS APPLY ( SELECT FROM someotherplace t WHERE t.key = r.key )...
At each recursive level you can have some success with windowing functions. Therefore, at each recursive level you can use aggregates with OVER clause. Why some success? well check that MS Connect link. Some don't work as expected. If they did, you could row_number() at each level, get max( from derived table where row_number (level data set)) OVER () at each level and then start the next ...
Some limitations or funky behaviour is certainly due to backwards compatibility issue. But a more common reason is that even Microsoft has limited resources and at some point they have to ship. As for the limitation to 8K in the CLR, this restriction has been lifted in SQL 2008, so that you can define CLR UDTs and CLR aggregates that can produce more than 8000 bytes. > Hopefully soon we get ...
That's true, I think there is also a mindset in the sqlserver team. The dot net team seems to have a policy of giving users as much flexibility as possible where sqlserver team seems to restrict users. That's obviously not the only reason but it's got to be a contributing factor. > As for the limitation to 8K in the CLR, this restriction has been lifted > in SQL 2008, so that you can ...
That must explain ahy in VB .Net can write: Using cn As SqlConnection = setup_connection(), _ cmd As SqlCommand = cn.CreateCommand() But I in C# has to write: using (SqlConnection cn = setup_connection()) { using (SqlCommand cmd = cn.CreateCommand()) { > That I know but to place an 8K restriction on this is a perfect of example > of the sqlserver team ...
Since we're really stretching the definition of "support for TVPs", we can surely stretch the definition of "support for digestion" to include the Food Network. As you say, it depends on how you look at it, if you choose to look at it that way. :) The fact that the LINQ providers have no support for TVPs is not even a question. The fact that you can kludge around the lack...
Permit me to point out that in the programming trade, nothing is proven to work until code is written and tested. Later in the thread, you can this sample: SqlCommand command = CodeToCreateMyCommand(); command.parameters["MyTableVariable"].Value = ResultsFromMyLinqQuery(); command.Execute(); This sample is not likely to work of the simple reason that you fail to set the parameter type. You also...
At each recursive level you can have some success with windowing functions. Therefore, at each recursive level you can use aggregates with OVER clause. Why some success? well check that MS Connect link. Some don't work as expected. If they did, you could row_number() at each level, get max( from derived table where row_number (level data set)) OVER () at each level and then start the next ireration level with r.max_prev_iteration +...
Hi Klem, Simple - because that are the limitation the development team chose to put in place. <speculation mode on> Allowing these options would probably allow users to write queries that were too hard to figure out how to do, or that would require more development time than was necessary. Evey option allowed adds to the complexion of the final product. Remember that if an option is allowed, customers will expect it to work in...
MS SQL Server is a minimal subset of the ANSI/ISO Standards. In Standard SQL, the WITH clause is "WITH [RECURSIVE]<cte name>" so that the compiler gets to change modes when a CTE is recursive. There are other differences. I am at speaking at PASS now and then going to SQL Connections, so I do not have my Standards with me; Google around for it. I think the Standard might allow for...
Spent 2 days writing slow recursive queries only to... Spent 2 days writing slow recursive queries only to realise I was neglecting the most obvious (and quick) solution! ah sql you lateralist! 5:05 PM May 20th from Nambu
Thread profile page for "Why can’t recursive queries contain...?" on http://www.sqlmonster.com.
This report page is a snippet summary view from a single thread "Why can’t recursive queries contain...?", located on the Message Board at http://www.sqlmonster.com.
This thread profile page shows the thread statistics for: Total Authors, Total Thread Posts, and Thread Activity