From paul.hartland at googlemail.com Thu Oct 10 07:01:05 2013 From: paul.hartland at googlemail.com (Paul Hartland) Date: Thu, 10 Oct 2013 13:01:05 +0100 Subject: [dba-SQLServer] SSRS Dashboard Message-ID: To all, I have about 3 years experience in creating reports in SSRS, from a basic employee listing to finance information with drill-down and drill-through reports. I have never created a dashboard, is a dashboard basically just one big report with various graphs and other data on ? Thanks for any info in advance, -- Paul Hartland paul.hartland at googlemail.com From fhtapia at gmail.com Thu Oct 10 07:08:28 2013 From: fhtapia at gmail.com (Francisco Tapia) Date: Thu, 10 Oct 2013 05:08:28 -0700 Subject: [dba-SQLServer] SSRS Dashboard In-Reply-To: References: Message-ID: <3D30FBF2-56DF-445A-8994-1D2FE676A3B9@gmail.com> Yes, It would be the default view to any of your drill down reports already available. Sent from my iPhone > On Oct 10, 2013, at 5:01 AM, Paul Hartland wrote: > > To all, > > I have about 3 years experience in creating reports in SSRS, from a basic > employee listing to finance information with drill-down and drill-through > reports. I have never created a dashboard, is a dashboard basically just > one big report with various graphs and other data on ? > > Thanks for any info in advance, > > -- > Paul Hartland > paul.hartland at googlemail.com > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > From mwp.reid at qub.ac.uk Thu Oct 10 07:10:13 2013 From: mwp.reid at qub.ac.uk (Martin Reid) Date: Thu, 10 Oct 2013 13:10:13 +0100 Subject: [dba-SQLServer] SSRS Dashboard In-Reply-To: <3D30FBF2-56DF-445A-8994-1D2FE676A3B9@gmail.com> References: <3D30FBF2-56DF-445A-8994-1D2FE676A3B9@gmail.com> Message-ID: <631CF83223105545BF43EFB52CB082959C5AE1C2D4@EX2K7-VIRT-2.ads.qub.ac.uk> That's how we do it. We have an index page containing the highlights with a drill down on each one. Martin -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Francisco Tapia Sent: 10 October 2013 13:08 To: Discussion concerning MS SQL Server Cc: SQLServerList Subject: Re: [dba-SQLServer] SSRS Dashboard Yes, It would be the default view to any of your drill down reports already available. Sent from my iPhone > On Oct 10, 2013, at 5:01 AM, Paul Hartland wrote: > > To all, > > I have about 3 years experience in creating reports in SSRS, from a > basic employee listing to finance information with drill-down and > drill-through reports. I have never created a dashboard, is a > dashboard basically just one big report with various graphs and other data on ? > > Thanks for any info in advance, > > -- > Paul Hartland > paul.hartland at googlemail.com > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From paul.hartland at googlemail.com Thu Oct 10 07:21:27 2013 From: paul.hartland at googlemail.com (Paul Hartland) Date: Thu, 10 Oct 2013 13:21:27 +0100 Subject: [dba-SQLServer] SSRS Dashboard In-Reply-To: <631CF83223105545BF43EFB52CB082959C5AE1C2D4@EX2K7-VIRT-2.ads.qub.ac.uk> References: <3D30FBF2-56DF-445A-8994-1D2FE676A3B9@gmail.com> <631CF83223105545BF43EFB52CB082959C5AE1C2D4@EX2K7-VIRT-2.ads.qub.ac.uk> Message-ID: ah ha, thought so cool, thank you both... Paul On 10 October 2013 13:10, Martin Reid wrote: > That's how we do it. We have an index page containing the highlights with > a drill down on each one. > > Martin > > > -----Original Message----- > From: dba-sqlserver-bounces at databaseadvisors.com [mailto: > dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Francisco Tapia > Sent: 10 October 2013 13:08 > To: Discussion concerning MS SQL Server > Cc: SQLServerList > Subject: Re: [dba-SQLServer] SSRS Dashboard > > Yes, > It would be the default view to any of your drill down reports already > available. > > Sent from my iPhone > > > On Oct 10, 2013, at 5:01 AM, Paul Hartland > wrote: > > > > To all, > > > > I have about 3 years experience in creating reports in SSRS, from a > > basic employee listing to finance information with drill-down and > > drill-through reports. I have never created a dashboard, is a > > dashboard basically just one big report with various graphs and other > data on ? > > > > Thanks for any info in advance, > > > > -- > > Paul Hartland > > paul.hartland at googlemail.com > > _______________________________________________ > > dba-SQLServer mailing list > > dba-SQLServer at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > > http://www.databaseadvisors.com > > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > -- Paul Hartland paul.hartland at googlemail.com From fuller.artful at gmail.com Sun Oct 13 11:42:44 2013 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sun, 13 Oct 2013 12:42:44 -0400 Subject: [dba-SQLServer] Remote ETL Message-ID: Lately I've begun work on a project which involves migration from an inadequate solution to a much more beautiful solution. Both solutions are web-UI. I need to migrate a bunch of data from the old system to the new system. In neither case do I have access using trusty tools such as SSMS. I think that I have worked around this by a) exporting the data from the old system to CSV files, then inhaling them into a new SQL database on my home machine. But although I've dipped into the docs about remote servers, etc., I have never actually had the need to do this. So I have a few questions.... Is it possible that from my home, I can set up remote connections to both the old and the new systems? If so, what info about these instances will I need to set up the connections? So far I have logins to both but no apparent access to their SSMS installations, so my hands are somewhat tied with respect to this setup. Assuming that both vendors would be willing to supply the info required for a direct connection (i.e. I run SSMS from home and connect to both databases, each of which resides in a far-off place), is this possible? So actually there would be three objects: databases A and B, and my home machine running SSMS+SSIS, so I can inspect and compare the db structures in both places and write an ETL package that transports data from A to B. I've done this sort of thing locally (in my home) but never yet to two remote instances. Any advice, guidance, pointers to tutorials, etc. shall be gratefully received. -- Arthur From mcp2004 at mail.ru Sun Oct 13 16:09:51 2013 From: mcp2004 at mail.ru (=?UTF-8?B?U2FsYWtoZXRkaW5vdiBTaGFtaWw=?=) Date: Mon, 14 Oct 2013 01:09:51 +0400 Subject: [dba-SQLServer] =?utf-8?q?Remote_ETL?= In-Reply-To: References: Message-ID: <1381698591.844857341@f210.i.mail.ru> Hi Arthur -- Read the following KB article: ?http://support.microsoft.com/kb/287932 it describes the process of communication of a client app (SSMS in your case) with remote MS SQL Server(s) over TCP/IP using WinSock. FYI: I'm using SSMS here with my ASP.NET hosting provider (parking.ru) and my hosted ?MS SQL Server databases connection strings are looking something like the following: Data Source=myTestMsSql.corp.parking.ru;Initial Catalog=myDatabase;User ID=myUserName;Password=myPassword or they could also be: Data Source = 190.190.200.100,1433; Initial Catalog = myDataBase; User ID = myUsername; Password = myPassword; Such a connection works well here even via mobile GSM modem. BTW, AFAIK there are quite a few ASP.NET providers worldwide, which you can sign up for a free usually for two weeks trial period to test how SSMS remote connection will work for you. Thank you. -- Shamil Sunday, October 13, 2013 12:42 PM -04:00 from Arthur Fuller : >Lately I've begun work on a project which involves migration from an >inadequate solution to a much more beautiful solution. Both solutions are >web-UI. I need to migrate a bunch of data from the old system to the new >system. In neither case do I have access using trusty tools such as SSMS. > >I think that I have worked around this by a) exporting the data from the >old system to CSV files, then inhaling them into a new SQL database on my >home machine. But although I've dipped into the docs about remote servers, >etc., I have never actually had the need to do this. So I have a few >questions.... > >Is it possible that from my home, I can set up remote connections to both >the old and the new systems? If so, what info about these instances will I >need to set up the connections? So far I have logins to both but no >apparent access to their SSMS installations, so my hands are somewhat tied >with respect to this setup. > >Assuming that both vendors would be willing to supply the info required for >a direct connection (i.e. I run SSMS from home and connect to both >databases, each of which resides in a far-off place), is this possible? So >actually there would be three objects: databases A and B, and my home >machine running SSMS+SSIS, so I can inspect and compare the db structures >in both places and write an ETL package that transports data from A to B. > >I've done this sort of thing locally (in my home) but never yet to two >remote instances. > >Any advice, guidance, pointers to tutorials, etc. shall be gratefully >received. > >-- >Arthur >_______________________________________________ > -- ???????????? ?????? From stuart at lexacorp.com.pg Sun Oct 13 16:42:01 2013 From: stuart at lexacorp.com.pg (Stuart McLachlan) Date: Mon, 14 Oct 2013 07:42:01 +1000 Subject: [dba-SQLServer] Remote ETL In-Reply-To: References: Message-ID: <525B13A9.3780.56A0FDA6@stuart.lexacorp.com.pg> If it's a public/ISP hosted SQL database, it is likely that they have disabled remote access as a security measure - many/most do. In that case, the only way to read/write data will be from their hosted web server's IP address. In that case, you will have to FTP the data to the server and update the tables using the tools available on the web server -- Stuart On 13 Oct 2013 at 12:42, Arthur Fuller wrote: > Lately I've begun work on a project which involves migration from an > inadequate solution to a much more beautiful solution. Both solutions are > web-UI. I need to migrate a bunch of data from the old system to the new > system. In neither case do I have access using trusty tools such as SSMS. > > I think that I have worked around this by a) exporting the data from the > old system to CSV files, then inhaling them into a new SQL database on my > home machine. But although I've dipped into the docs about remote servers, > etc., I have never actually had the need to do this. So I have a few > questions.... > > Is it possible that from my home, I can set up remote connections to both > the old and the new systems? If so, what info about these instances will I > need to set up the connections? So far I have logins to both but no > apparent access to their SSMS installations, so my hands are somewhat tied > with respect to this setup. > > Assuming that both vendors would be willing to supply the info required for > a direct connection (i.e. I run SSMS from home and connect to both > databases, each of which resides in a far-off place), is this possible? So > actually there would be three objects: databases A and B, and my home > machine running SSMS+SSIS, so I can inspect and compare the db structures > in both places and write an ETL package that transports data from A to B. > > I've done this sort of thing locally (in my home) but never yet to two > remote instances. > > Any advice, guidance, pointers to tutorials, etc. shall be gratefully > received. > > -- > Arthur > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From mwp.reid at qub.ac.uk Mon Oct 14 02:05:39 2013 From: mwp.reid at qub.ac.uk (Martin Reid) Date: Mon, 14 Oct 2013 08:05:39 +0100 Subject: [dba-SQLServer] Remote ETL In-Reply-To: <525B13A9.3780.56A0FDA6@stuart.lexacorp.com.pg> References: <525B13A9.3780.56A0FDA6@stuart.lexacorp.com.pg> Message-ID: <631CF83223105545BF43EFB52CB082959C5AE1CB4A@EX2K7-VIRT-2.ads.qub.ac.uk> Arthur Had a similar requirement to a remote hosted MYSQL database. They give access to the MYSQL database from a specific IP. Once that was done we simply used the SQL Server 2012 Data Tools to create the DTS packages. If you remember you answered a question about the drivers. Martin From fuller.artful at gmail.com Mon Oct 14 02:59:10 2013 From: fuller.artful at gmail.com (Arthur Fuller) Date: Mon, 14 Oct 2013 03:59:10 -0400 Subject: [dba-SQLServer] Remote ETL In-Reply-To: <631CF83223105545BF43EFB52CB082959C5AE1CB4A@EX2K7-VIRT-2.ads.qub.ac.uk> References: <525B13A9.3780.56A0FDA6@stuart.lexacorp.com.pg> <631CF83223105545BF43EFB52CB082959C5AE1CB4A@EX2K7-VIRT-2.ads.qub.ac.uk> Message-ID: Thanks, Shamil, Stuart and Martin. I shall investigate and see what can be done. Arthur On Mon, Oct 14, 2013 at 3:05 AM, Martin Reid wrote: > Arthur > > Had a similar requirement to a remote hosted MYSQL database. They give > access to the MYSQL database from a specific IP. Once that was done we > simply used the SQL Server 2012 Data Tools to create the DTS packages. > > If you remember you answered a question about the drivers. > > Martin > > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > -- Arthur From fuller.artful at gmail.com Fri Oct 18 08:27:04 2013 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 18 Oct 2013 09:27:04 -0400 Subject: [dba-SQLServer] Oracle blasts OSS Message-ID: >From slashdot... *"Oracle has a love-hate relationship with open source technologies. In a whitepaper(PDF) for the Deparment of Defense, Oracle claims that TCO (total cost of ownership) goes up with the use of open source. They're essentially trying to build a case for the use of their own products within the government. 'The skill required to successfully and economically blend source code into a commercially viable product is relatively scarce. It should not be done directly at government expense.' Oracle also attacks the community-based development model, calling it more insecure than company developed products. 'Government-sponsored community development approaches to software creation lack the financial incentives of commercial companies to produce low-defect, well-documented code.'" * How exactly this fits in with the (indirect) acquisition of MySQL remains to be seen. Maybe Larry just has too much money. -- Arthur From accessd at shaw.ca Sat Oct 19 04:28:09 2013 From: accessd at shaw.ca (Jim Lawrence) Date: Sat, 19 Oct 2013 03:28:09 -0600 (MDT) Subject: [dba-SQLServer] Oracle blasts OSS In-Reply-To: Message-ID: <945880681.35459303.1382174889056.JavaMail.root@cds002> Hi Arthur: Oracle's market position has been slowly eroding. Oracle has always been looked upon as the product for big-data but the NoSQL databases have been eating away at sales. The TOC of Oracle is also in the hardware it needs. Big sites in the government have some substantial farms of Oracle with top of the line servers...Oracle is not truly distributive not like the host of new systems out there...which can scale with ease to any size and are not equipment dependant. As for security, Oracle would have a very hard case to make, to prove its OSS challengers are less secure...in fact the reverse is probably true. OTOH Oracle is probably correct when it says there is a lack of qualified new age support techs out there but that is changing quickly. Aside: For the record MySQL growth has flat-lined. Maybe Larry is worried that he is losing his business? Jim ----- Original Message ----- From: "Arthur Fuller" To: "Discussion concerning MS SQL Server" Sent: Friday, October 18, 2013 6:27:04 AM Subject: [dba-SQLServer] Oracle blasts OSS >From slashdot... *"Oracle has a love-hate relationship with open source technologies. In a whitepaper(PDF) for the Deparment of Defense, Oracle claims that TCO (total cost of ownership) goes up with the use of open source. They're essentially trying to build a case for the use of their own products within the government. 'The skill required to successfully and economically blend source code into a commercially viable product is relatively scarce. It should not be done directly at government expense.' Oracle also attacks the community-based development model, calling it more insecure than company developed products. 'Government-sponsored community development approaches to software creation lack the financial incentives of commercial companies to produce low-defect, well-documented code.'" * How exactly this fits in with the (indirect) acquisition of MySQL remains to be seen. Maybe Larry just has too much money. -- Arthur _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From fuller.artful at gmail.com Sat Oct 19 04:45:37 2013 From: fuller.artful at gmail.com (Arthur Fuller) Date: Sat, 19 Oct 2013 05:45:37 -0400 Subject: [dba-SQLServer] Oracle blasts OSS In-Reply-To: <945880681.35459303.1382174889056.JavaMail.root@cds002> References: <945880681.35459303.1382174889056.JavaMail.root@cds002> Message-ID: Jim, Regarding MySQL's flat-lining, I wonder how much these facts have to do with that: 1. Not many people like Oracle and Larry in particular, especially in the Linux community. 2. Google has kicked both money and people into MariaDB, lending it a lot more credibility. 3. A couple of distros have dropped MySQL in favour of Maria. 4. Maria is a drop-in replacement for MySQL. 5. Maria has several significant new features not yet present in MySQL. Arthur From accessd at shaw.ca Sat Oct 19 05:59:12 2013 From: accessd at shaw.ca (Jim Lawrence) Date: Sat, 19 Oct 2013 04:59:12 -0600 (MDT) Subject: [dba-SQLServer] Oracle blasts OSS In-Reply-To: Message-ID: <1689591896.35479153.1382180352083.JavaMail.root@cds002> Hi Arthur: I think you have well covered the main points. Jim ----- Original Message ----- From: "Arthur Fuller" To: "Discussion concerning MS SQL Server" Sent: Saturday, October 19, 2013 2:45:37 AM Subject: Re: [dba-SQLServer] Oracle blasts OSS Jim, Regarding MySQL's flat-lining, I wonder how much these facts have to do with that: 1. Not many people like Oracle and Larry in particular, especially in the Linux community. 2. Google has kicked both money and people into MariaDB, lending it a lot more credibility. 3. A couple of distros have dropped MySQL in favour of Maria. 4. Maria is a drop-in replacement for MySQL. 5. Maria has several significant new features not yet present in MySQL. Arthur _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From gustav at cactus.dk Mon Oct 28 08:28:18 2013 From: gustav at cactus.dk (Gustav Brock) Date: Mon, 28 Oct 2013 14:28:18 +0100 Subject: [dba-SQLServer] Recursive Queries in Microsoft SQL Server 2008 Message-ID: <012801ced3e1$90c8e3b0$b25aab10$@cactus.dk> Hi all I'm a noob when it comes to T-SQL - try to limit myself to tables and views - so could someone please explain what is going on here? What does this WITH mean? How would you retrieve the data from Access? Is "vParent = null" valid code in T-SQL? Why not "vParent is null"? WITH security_menu_Recursive(Parent,MenuId,MenuName,LEVEL) AS ( SELECT vparent,vmenuid,vmenuname,0 AS LEVEL FROM dbo.SecurityMenu WHERE vParent = null UNION ALL SELECT vparent,vmenuid,vmenuname,Level + 1 AS LEVEL FROM dbo.SecurityMenu INNER JOIN security_menu_Recursive AS smr ON smr.menuid = dbo.SecurityMenu.vParent ) SELECT parent,menuid,menuname,LEVEL FROM security_menu_Recursive The full tip is here: http://www.codeproject.com/Articles/674287/Recursive-Queries-in-Microsoft-SQ L-Server-2008 /gustav From fuller.artful at gmail.com Mon Oct 28 08:39:34 2013 From: fuller.artful at gmail.com (Arthur Fuller) Date: Mon, 28 Oct 2013 09:39:34 -0400 Subject: [dba-SQLServer] Recursive Queries in Microsoft SQL Server 2008 In-Reply-To: <012801ced3e1$90c8e3b0$b25aab10$@cactus.dk> References: <012801ced3e1$90c8e3b0$b25aab10$@cactus.dk> Message-ID: Gustav, Following the WITH is the name of the alias being defined, along with its parameter, and its definition follows the first AS. Now jump down to the INNER JOIN line, and notice that it's calling itself (i.e. the alias just defined). So each row has a menuid and also a parentid. What the JOIN does is link the child rows to their parent using their parentid to their parent's menuid. In other words it's a self-join; the table is joined to itself. The child rows' parentid contains the menuid that identifies its parent row. Because it's an INNER JOIN, eventually it will fail, in which case you've traversed the tree all the way to its outermost leaves. Does that help? Arthur On Mon, Oct 28, 2013 at 9:28 AM, Gustav Brock wrote: > Hi all > > I'm a noob when it comes to T-SQL - try to limit myself to tables and views > - so could someone please explain what is going on here? > What does this WITH mean? > How would you retrieve the data from Access? > Is "vParent = null" valid code in T-SQL? Why not "vParent is null"? > > > WITH security_menu_Recursive(Parent,MenuId,MenuName,LEVEL) > AS > ( > SELECT vparent,vmenuid,vmenuname,0 AS LEVEL FROM dbo.SecurityMenu WHERE > vParent = null > UNION ALL > SELECT vparent,vmenuid,vmenuname,Level + 1 AS LEVEL FROM > dbo.SecurityMenu > INNER JOIN security_menu_Recursive AS smr ON smr.menuid = > dbo.SecurityMenu.vParent > ) > SELECT parent,menuid,menuname,LEVEL FROM security_menu_Recursive > > > The full tip is here: > > > http://www.codeproject.com/Articles/674287/Recursive-Queries-in-Microsoft-SQ > L-Server-2008 > > /gustav > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > -- Arthur From gustav at cactus.dk Mon Oct 28 10:06:34 2013 From: gustav at cactus.dk (Gustav Brock) Date: Mon, 28 Oct 2013 16:06:34 +0100 Subject: [dba-SQLServer] Recursive Queries in Microsoft SQL Server 2008 Message-ID: <000001ced3ef$4b2a9750$e17fc5f0$@cactus.dk> Hi Arthur So the WITH .. AS isolates the inner part? Normally, in pure SQL, you can't let a query pull data from itself without getting a circular reference error or the like. /gustav -----Oprindelig meddelelse----- Fra: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Arthur Fuller Sendt: 28. oktober 2013 14:40 Til: Discussion concerning MS SQL Server Emne: Re: [dba-SQLServer] Recursive Queries in Microsoft SQL Server 2008 Gustav, Following the WITH is the name of the alias being defined, along with its parameter, and its definition follows the first AS. Now jump down to the INNER JOIN line, and notice that it's calling itself (i.e. the alias just defined). So each row has a menuid and also a parentid. What the JOIN does is link the child rows to their parent using their parentid to their parent's menuid. In other words it's a self-join; the table is joined to itself. The child rows' parentid contains the menuid that identifies its parent row. Because it's an INNER JOIN, eventually it will fail, in which case you've traversed the tree all the way to its outermost leaves. Does that help? Arthur On Mon, Oct 28, 2013 at 9:28 AM, Gustav Brock wrote: > Hi all > > I'm a noob when it comes to T-SQL - try to limit myself to tables and views > - so could someone please explain what is going on here? > What does this WITH mean? > How would you retrieve the data from Access? > Is "vParent = null" valid code in T-SQL? Why not "vParent is null"? > > > WITH security_menu_Recursive(Parent,MenuId,MenuName,LEVEL) AS > ( > SELECT vparent,vmenuid,vmenuname,0 AS LEVEL FROM dbo.SecurityMenu WHERE vParent = null > UNION ALL > SELECT vparent,vmenuid,vmenuname,Level + 1 AS LEVEL FROM dbo.SecurityMenu > INNER JOIN security_menu_Recursive AS smr ON smr.menuid = dbo.SecurityMenu.vParent > ) > SELECT parent,menuid,menuname,LEVEL FROM security_menu_Recursive > > > The full tip is here: > > > http://www.codeproject.com/Articles/674287/Recursive-Queries-in-Microsoft-SQ L-Server-2008 > > /gustav From fuller.artful at gmail.com Mon Oct 28 10:34:07 2013 From: fuller.artful at gmail.com (Arthur Fuller) Date: Mon, 28 Oct 2013 11:34:07 -0400 Subject: [dba-SQLServer] Recursive Queries in Microsoft SQL Server 2008 In-Reply-To: <000001ced3ef$4b2a9750$e17fc5f0$@cactus.dk> References: <000001ced3ef$4b2a9750$e17fc5f0$@cactus.dk> Message-ID: Gustav, Yes and no. Somewhere on TechRepublic there's an article by me that discusses recursive SQL within a stored procedure. If you can't find it, I have a copy in Word format that I could send you off-list, but their search is pretty good. Try "recursion in t-sql". If that doesn't work try searching for my name and that ought to find it. Anyway, you're right: The WITH AS (SELECT...) construct is T-SQL not pure SQL. In essence, what you're doing is creating a virtual temp table and then joining that to the real table (or view). And you're also wrong. In pure SQL it's quite common to join a table or view to itself. One typical use of this technique is to find the second-last item in a set (which you do by joining a set to itself but the WHERE clause uses a "<" comparison rather than an "=". Combine that with an ORDER BY ... DESC and you get the previous row. If that's a little fuzzy, I'll supply an example, but I encourage you to ponder it first. LOL. Arthur On Mon, Oct 28, 2013 at 11:06 AM, Gustav Brock wrote: > Hi Arthur > > So the WITH .. AS isolates the inner part? > Normally, in pure SQL, you can't let a query pull data from itself without > getting a circular reference error or the like. > > /gustav > > From gustav at cactus.dk Mon Oct 28 11:43:33 2013 From: gustav at cactus.dk (Gustav Brock) Date: Mon, 28 Oct 2013 17:43:33 +0100 Subject: [dba-SQLServer] Recursive Queries in Microsoft SQL Server 2008 Message-ID: <000e01ced3fc$d70e9700$852bc500$@cactus.dk> Hi Arthur I think I recall that article. But wasn't that about a limited/fixed number of sublevels? True recursion should just continue one level down until no more levels are found, no matter how many levels. /gustav -----Oprindelig meddelelse----- Fra: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Arthur Fuller Sendt: 28. oktober 2013 16:34 Til: Discussion concerning MS SQL Server Emne: Re: [dba-SQLServer] Recursive Queries in Microsoft SQL Server 2008 Gustav, Yes and no. Somewhere on TechRepublic there's an article by me that discusses recursive SQL within a stored procedure. If you can't find it, I have a copy in Word format that I could send you off-list, but their search is pretty good. Try "recursion in t-sql". If that doesn't work try searching for my name and that ought to find it. Anyway, you're right: The WITH AS (SELECT...) construct is T-SQL not pure SQL. In essence, what you're doing is creating a virtual temp table and then joining that to the real table (or view). And you're also wrong. In pure SQL it's quite common to join a table or view to itself. One typical use of this technique is to find the second-last item in a set (which you do by joining a set to itself but the WHERE clause uses a "<" comparison rather than an "=". Combine that with an ORDER BY ... DESC and you get the previous row. If that's a little fuzzy, I'll supply an example, but I encourage you to ponder it first. LOL. Arthur On Mon, Oct 28, 2013 at 11:06 AM, Gustav Brock wrote: > Hi Arthur > > So the WITH .. AS isolates the inner part? > Normally, in pure SQL, you can't let a query pull data from itself > without getting a circular reference error or the like. > > /gustav From accessd at shaw.ca Mon Oct 28 14:02:54 2013 From: accessd at shaw.ca (Jim Lawrence) Date: Mon, 28 Oct 2013 13:02:54 -0600 (MDT) Subject: [dba-SQLServer] Recursive Queries in Microsoft SQL Server 2008 In-Reply-To: <000e01ced3fc$d70e9700$852bc500$@cactus.dk> Message-ID: <57357820.43842273.1382986974189.JavaMail.root@cds002> Just an off side note: Oracle 10.x to 11.x used to have a limit of 6 levels and at the time MS SQL had only one level...I would suspect that MS SQL now has no such level limit. The one thing I noted was that more that one level deep could bring my client's servers to "its knees" so to speak, so used multiple temp files instead. MS SQL may have a resolution for that problem. Jim ----- Original Message ----- From: "Gustav Brock" To: "Discussion concerning MS SQL Server" Sent: Monday, October 28, 2013 9:43:33 AM Subject: Re: [dba-SQLServer] Recursive Queries in Microsoft SQL Server 2008 Hi Arthur I think I recall that article. But wasn't that about a limited/fixed number of sublevels? True recursion should just continue one level down until no more levels are found, no matter how many levels. /gustav -----Oprindelig meddelelse----- Fra: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Arthur Fuller Sendt: 28. oktober 2013 16:34 Til: Discussion concerning MS SQL Server Emne: Re: [dba-SQLServer] Recursive Queries in Microsoft SQL Server 2008 Gustav, Yes and no. Somewhere on TechRepublic there's an article by me that discusses recursive SQL within a stored procedure. If you can't find it, I have a copy in Word format that I could send you off-list, but their search is pretty good. Try "recursion in t-sql". If that doesn't work try searching for my name and that ought to find it. Anyway, you're right: The WITH AS (SELECT...) construct is T-SQL not pure SQL. In essence, what you're doing is creating a virtual temp table and then joining that to the real table (or view). And you're also wrong. In pure SQL it's quite common to join a table or view to itself. One typical use of this technique is to find the second-last item in a set (which you do by joining a set to itself but the WHERE clause uses a "<" comparison rather than an "=". Combine that with an ORDER BY ... DESC and you get the previous row. If that's a little fuzzy, I'll supply an example, but I encourage you to ponder it first. LOL. Arthur On Mon, Oct 28, 2013 at 11:06 AM, Gustav Brock wrote: > Hi Arthur > > So the WITH .. AS isolates the inner part? > Normally, in pure SQL, you can't let a query pull data from itself > without getting a circular reference error or the like. > > /gustav _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From fuller.artful at gmail.com Mon Oct 28 14:56:58 2013 From: fuller.artful at gmail.com (Arthur Fuller) Date: Mon, 28 Oct 2013 15:56:58 -0400 Subject: [dba-SQLServer] Recursive Queries in Microsoft SQL Server 2008 In-Reply-To: <57357820.43842273.1382986974189.JavaMail.root@cds002> References: <000e01ced3fc$d70e9700$852bc500$@cactus.dk> <57357820.43842273.1382986974189.JavaMail.root@cds002> Message-ID: Two distinct questions here, and this concerns graph theory (see the chapter on this subject at www.artfulsoftware.com). Short answer is this: for performance, define a depth, else risk the consumptive levels of performance. Slightly longer answer: if you have not already separated your OLTP requirements from your data-analysis requirements, then wake up and smell the servers! I'm not even talking Big Data here. As in all things regarding databases, we're dealing with trade-offs, but the bottom line is, "Separate the requirements of the OLTP part from the requirements of the OLAP part." Basic rule. Two databases, in relative synch, but the OLAP instance is guaranteed not to be up to the moment; a few seconds or minutes or even hours behind, but the circumstances in which the OLAP part must be within minutes or seconds from the OLTP part are extremely few and far between. Analysis of the history should, IMO, seldom if never occur via direct inquiry upon the OLTP instance, since such interrogations inevitably demand aggregations, which are hugely expensive, and slow down the basic nature of OLTP, which is to generate income. Slow that part down and here's a shotgun and there is your foot, as it were. Back to Jim's point: Oracle made an intelligent decision in limiting recursive levels, but IMO this decision was based on the faulty assumption that one was interrogating the OLTP database rather than the OLAP instance, and perhaps further, that these two instances reside upon the same physical server. Two mistakes, rolled into one bad decision. In a high-traffic situation, the OLTP instance should have one server and the OLAP instance reside on another physical server. Should the licensing costs prove prohibitive, then switch to MySQL or MariaDB or PostGres. The bottom line is, for managerial analyses, use a separate instance, else risk performance on the OLTP side of things, which is the firm's bread and butter. Various replication techniques can shrink the window between OLTP and OLAP to a few minutes. Think of it this way: how many bytes must be transmitted per hour or minute to update the OLAP instance? A given order and its details amount to how many bytes? In a normalized database where most of the delay-columns are FKs into related tables, all we're really talking about is a few KB per transaction, so even if they come in at 1000 per second, it's not that big a problem. So the OLAP instance is a few seconds or even minutes behind. If management can't live with that, then I'm in search of another job. Even Google, with its fantastic scaled-out engineering, does not guarantee contemporaneous results. No one can. Database apps are all about trade-offs. Be realistic about this. Tell Management that their results are subject to a temporal window, which depending upon the hardware and the implementation and the budget, might vary from an hour to a few minutes to a few seconds. The point is, the money comes from the OLTP part, and the decisions come from the OLAP part, and let's not step on our udder while trying to obtain some more food. IME and IMO, any attempt to use the OLTP instance as the reporting instance is doomed to fail -- especially so in the case when the OLTP instance is successful. Don't undermine its success with analysis. That's not its job. That job is for the OLAP instance. Combining them in a single instance is equivalent to saying to the potential customer, "Yes I will sell you this, but first I need you to fill out this 20-question form." Duh! Final thought: in the face of opposition from managerial folks, just tell them that "Real Time" means "an hour ago". Arthur On Mon, Oct 28, 2013 at 3:02 PM, Jim Lawrence wrote: > Just an off side note: Oracle 10.x to 11.x used to have a limit of 6 > levels and at the time MS SQL had only one level...I would suspect that MS > SQL now has no such level limit. The one thing I noted was that more that > one level deep could bring my client's servers to "its knees" so to speak, > so used multiple temp files instead. MS SQL may have a resolution for that > problem. > > Jim > > ----- Original Message ----- > From: "Gustav Brock" > To: "Discussion concerning MS SQL Server" < > dba-sqlserver at databaseadvisors.com> > Sent: Monday, October 28, 2013 9:43:33 AM > Subject: Re: [dba-SQLServer] Recursive Queries in Microsoft SQL Server 2008 > > Hi Arthur > > I think I recall that article. But wasn't that about a limited/fixed number > of sublevels? True recursion should just continue one level down until no > more levels are found, no matter how many levels. > > /gustav > > -----Oprindelig meddelelse----- > Fra: dba-sqlserver-bounces at databaseadvisors.com > [mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Arthur > Fuller > Sendt: 28. oktober 2013 16:34 > Til: Discussion concerning MS SQL Server > Emne: Re: [dba-SQLServer] Recursive Queries in Microsoft SQL Server 2008 > > Gustav, > > Yes and no. Somewhere on TechRepublic there's an article by me that > discusses recursive SQL within a stored procedure. If you can't find it, I > have a copy in Word format that I could send you off-list, but their search > is pretty good. Try "recursion in t-sql". If that doesn't work try > searching > for my name and that ought to find it. > > Anyway, you're right: The WITH AS (SELECT...) construct is T-SQL not > pure SQL. In essence, what you're doing is creating a virtual temp table > and > then joining that to the real table (or view). > > And you're also wrong. In pure SQL it's quite common to join a table or > view > to itself. One typical use of this technique is to find the second-last > item > in a set (which you do by joining a set to itself but the WHERE clause uses > a "<" comparison rather than an "=". Combine that with an ORDER BY ... DESC > and you get the previous row. If that's a little fuzzy, I'll supply an > example, but I encourage you to ponder it first. LOL. > > Arthur > > > On Mon, Oct 28, 2013 at 11:06 AM, Gustav Brock wrote: > > > Hi Arthur > > > > So the WITH .. AS isolates the inner part? > > Normally, in pure SQL, you can't let a query pull data from itself > > without getting a circular reference error or the like. > > > > /gustav > > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > -- Arthur From stuart at lexacorp.com.pg Mon Oct 28 15:15:12 2013 From: stuart at lexacorp.com.pg (Stuart McLachlan) Date: Tue, 29 Oct 2013 06:15:12 +1000 Subject: [dba-SQLServer] Recursive Queries in Microsoft SQL Server 2008 In-Reply-To: References: <000e01ced3fc$d70e9700$852bc500$@cactus.dk>, <57357820.43842273.1382986974189.JavaMail.root@cds002>, Message-ID: <526EC5D0.17823.1C8FC9BA@stuart.lexacorp.com.pg> Oustanding analysis! I'm going to file this one for use in future discussions with "managerila types" -- Stuart On 28 Oct 2013 at 15:56, Arthur Fuller wrote: > Two distinct questions here, and this concerns graph theory (see the > chapter on this subject at www.artfulsoftware.com). Short answer is > this: for performance, define a depth, else risk the consumptive > levels of performance. Slightly longer answer: if you have not already > separated your OLTP requirements from your data-analysis requirements, > then wake up and smell the servers! I'm not even talking Big Data > here. As in all things regarding databases, we're dealing with > trade-offs, but the bottom line is, "Separate the requirements of the > OLTP part from the requirements of the OLAP part." Basic rule. Two > databases, in relative synch, but the OLAP instance is guaranteed not > to be up to the moment; a few seconds or minutes or even hours behind, > but the circumstances in which the OLAP part must be within minutes or > seconds from the OLTP part are extremely few and far between. Analysis > of the history should, IMO, seldom if never occur via direct inquiry > upon the OLTP instance, since such interrogations inevitably demand > aggregations, which are hugely expensive, and slow down the basic > nature of OLTP, which is to generate income. Slow that part down and > here's a shotgun and there is your foot, as it were. > > Back to Jim's point: Oracle made an intelligent decision in limiting > recursive levels, but IMO this decision was based on the faulty > assumption that one was interrogating the OLTP database rather than > the OLAP instance, and perhaps further, that these two instances > reside upon the same physical server. Two mistakes, rolled into one > bad decision. In a high-traffic situation, the OLTP instance should > have one server and the OLAP instance reside on another physical > server. Should the licensing costs prove prohibitive, then switch to > MySQL or MariaDB or PostGres. > > The bottom line is, for managerial analyses, use a separate instance, > else risk performance on the OLTP side of things, which is the firm's > bread and butter. Various replication techniques can shrink the window > between OLTP and OLAP to a few minutes. Think of it this way: how many > bytes must be transmitted per hour or minute to update the OLAP > instance? A given order and its details amount to how many bytes? In a > normalized database where most of the delay-columns are FKs into > related tables, all we're really talking about is a few KB per > transaction, so even if they come in at 1000 per second, it's not that > big a problem. So the OLAP instance is a few seconds or even minutes > behind. If management can't live with that, then I'm in search of > another job. Even Google, with its fantastic scaled-out engineering, > does not guarantee contemporaneous results. No one can. > > Database apps are all about trade-offs. Be realistic about this. Tell > Management that their results are subject to a temporal window, which > depending upon the hardware and the implementation and the budget, > might vary from an hour to a few minutes to a few seconds. The point > is, the money comes from the OLTP part, and the decisions come from > the OLAP part, and let's not step on our udder while trying to obtain > some more food. > > IME and IMO, any attempt to use the OLTP instance as the reporting > instance is doomed to fail -- especially so in the case when the OLTP > instance is successful. Don't undermine its success with analysis. > That's not its job. That job is for the OLAP instance. Combining them > in a single instance is equivalent to saying to the potential > customer, "Yes I will sell you this, but first I need you to fill out > this 20-question form." Duh! > > Final thought: in the face of opposition from managerial folks, just > tell them that "Real Time" means "an hour ago". > > Arthur > > > On Mon, Oct 28, 2013 at 3:02 PM, Jim Lawrence wrote: > > > Just an off side note: Oracle 10.x to 11.x used to have a limit of 6 > > levels and at the time MS SQL had only one level...I would suspect > > that MS SQL now has no such level limit. The one thing I noted was > > that more that one level deep could bring my client's servers to > > "its knees" so to speak, so used multiple temp files instead. MS SQL > > may have a resolution for that problem. > > > > Jim > > > > ----- Original Message ----- > > From: "Gustav Brock" > > To: "Discussion concerning MS SQL Server" < > > dba-sqlserver at databaseadvisors.com> > > Sent: Monday, October 28, 2013 9:43:33 AM > > Subject: Re: [dba-SQLServer] Recursive Queries in Microsoft SQL > > Server 2008 > > > > Hi Arthur > > > > I think I recall that article. But wasn't that about a limited/fixed > > number of sublevels? True recursion should just continue one level > > down until no more levels are found, no matter how many levels. > > > > /gustav > > > > -----Oprindelig meddelelse----- > > Fra: dba-sqlserver-bounces at databaseadvisors.com > > [mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af > > Arthur Fuller Sendt: 28. oktober 2013 16:34 Til: Discussion > > concerning MS SQL Server Emne: Re: [dba-SQLServer] Recursive Queries > > in Microsoft SQL Server 2008 > > > > Gustav, > > > > Yes and no. Somewhere on TechRepublic there's an article by me that > > discusses recursive SQL within a stored procedure. If you can't find > > it, I have a copy in Word format that I could send you off-list, but > > their search is pretty good. Try "recursion in t-sql". If that > > doesn't work try searching for my name and that ought to find it. > > > > Anyway, you're right: The WITH AS (SELECT...) construct is > > T-SQL not pure SQL. In essence, what you're doing is creating a > > virtual temp table and then joining that to the real table (or > > view). > > > > And you're also wrong. In pure SQL it's quite common to join a table > > or view to itself. One typical use of this technique is to find the > > second-last item in a set (which you do by joining a set to itself > > but the WHERE clause uses a "<" comparison rather than an "=". > > Combine that with an ORDER BY ... DESC and you get the previous row. > > If that's a little fuzzy, I'll supply an example, but I encourage > > you to ponder it first. LOL. > > > > Arthur > > > > > > On Mon, Oct 28, 2013 at 11:06 AM, Gustav Brock > > wrote: > > > > > Hi Arthur > > > > > > So the WITH .. AS isolates the inner part? > > > Normally, in pure SQL, you can't let a query pull data from itself > > > without getting a circular reference error or the like. > > > > > > /gustav > > > > > > > > _______________________________________________ > > dba-SQLServer mailing list > > dba-SQLServer at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > > http://www.databaseadvisors.com > > > > > > _______________________________________________ > > dba-SQLServer mailing list > > dba-SQLServer at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > > http://www.databaseadvisors.com > > > > > > > -- > Arthur > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From fuller.artful at gmail.com Mon Oct 28 22:30:14 2013 From: fuller.artful at gmail.com (Arthur Fuller) Date: Mon, 28 Oct 2013 23:30:14 -0400 Subject: [dba-SQLServer] Recursive Queries in Microsoft SQL Server 2008 In-Reply-To: <526EC5D0.17823.1C8FC9BA@stuart.lexacorp.com.pg> References: <000e01ced3fc$d70e9700$852bc500$@cactus.dk> <57357820.43842273.1382986974189.JavaMail.root@cds002> <526EC5D0.17823.1C8FC9BA@stuart.lexacorp.com.pg> Message-ID: Thanks, Stuart! Coming from you, that's seriously appreciated. Arthur On Mon, Oct 28, 2013 at 4:15 PM, Stuart McLachlan wrote: > Oustanding analysis! I'm going to file this one for use in future > discussions with > "managerila types" > > -- > Stuart > > From mwp.reid at qub.ac.uk Tue Oct 29 04:46:46 2013 From: mwp.reid at qub.ac.uk (Martin Reid) Date: Tue, 29 Oct 2013 09:46:46 +0000 Subject: [dba-SQLServer] Recursive Queries in Microsoft SQL Server 2008 In-Reply-To: References: <000e01ced3fc$d70e9700$852bc500$@cactus.dk> <57357820.43842273.1382986974189.JavaMail.root@cds002> Message-ID: <631CF83223105545BF43EFB52CB082959C5B26F71E@EX2K7-VIRT-2.ads.qub.ac.uk> Spot on Arthur. Like Stewart I have immediate need of this as well. Martin -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: 28 October 2013 19:57 To: Discussion concerning MS SQL Server Subject: Re: [dba-SQLServer] Recursive Queries in Microsoft SQL Server 2008 Two distinct questions here, and this concerns graph theory (see the chapter on this subject at www.artfulsoftware.com). Short answer is this: for performance, define a depth, else risk the consumptive levels of performance. Slightly longer answer: if you have not already separated your OLTP requirements from your data-analysis requirements, then wake up and smell the servers! I'm not even talking Big Data here. As in all things regarding databases, we're dealing with trade-offs, but the bottom line is, "Separate the requirements of the OLTP part from the requirements of the OLAP part." Basic rule. Two databases, in relative synch, but the OLAP instance is guaranteed not to be up to the moment; a few seconds or minutes or even hours behind, but the circumstances in which the OLAP part must be within minutes or seconds from the OLTP part are extremely few and far between. Analysis of the history should, IMO, seldom if never occur via direct inquiry upon the OLTP instance, since such interrogations inevitably demand aggregations, which are hugely expensive, and slow down the basic nature of OLTP, which is to generate income. Slow that part down and here's a shotgun and there is your foot, as it were. Back to Jim's point: Oracle made an intelligent decision in limiting recursive levels, but IMO this decision was based on the faulty assumption that one was interrogating the OLTP database rather than the OLAP instance, and perhaps further, that these two instances reside upon the same physical server. Two mistakes, rolled into one bad decision. In a high-traffic situation, the OLTP instance should have one server and the OLAP instance reside on another physical server. Should the licensing costs prove prohibitive, then switch to MySQL or MariaDB or PostGres. The bottom line is, for managerial analyses, use a separate instance, else risk performance on the OLTP side of things, which is the firm's bread and butter. Various replication techniques can shrink the window between OLTP and OLAP to a few minutes. Think of it this way: how many bytes must be transmitted per hour or minute to update the OLAP instance? A given order and its details amount to how many bytes? In a normalized database where most of the delay-columns are FKs into related tables, all we're really talking about is a few KB per transaction, so even if they come in at 1000 per second, it's not that big a problem. So the OLAP instance is a few seconds or even minutes behind. If management can't live with that, then I'm in search of another job. Even Google, with its fantastic scaled-out engineering, does not guarantee contemporaneous results. No one can. Database apps are all about trade-offs. Be realistic about this. Tell Management that their results are subject to a temporal window, which depending upon the hardware and the implementation and the budget, might vary from an hour to a few minutes to a few seconds. The point is, the money comes from the OLTP part, and the decisions come from the OLAP part, and let's not step on our udder while trying to obtain some more food. IME and IMO, any attempt to use the OLTP instance as the reporting instance is doomed to fail -- especially so in the case when the OLTP instance is successful. Don't undermine its success with analysis. That's not its job. That job is for the OLAP instance. Combining them in a single instance is equivalent to saying to the potential customer, "Yes I will sell you this, but first I need you to fill out this 20-question form." Duh! Final thought: in the face of opposition from managerial folks, just tell them that "Real Time" means "an hour ago". Arthur On Mon, Oct 28, 2013 at 3:02 PM, Jim Lawrence wrote: > Just an off side note: Oracle 10.x to 11.x used to have a limit of 6 > levels and at the time MS SQL had only one level...I would suspect > that MS SQL now has no such level limit. The one thing I noted was > that more that one level deep could bring my client's servers to "its > knees" so to speak, so used multiple temp files instead. MS SQL may > have a resolution for that problem. > > Jim > > ----- Original Message ----- > From: "Gustav Brock" > To: "Discussion concerning MS SQL Server" < > dba-sqlserver at databaseadvisors.com> > Sent: Monday, October 28, 2013 9:43:33 AM > Subject: Re: [dba-SQLServer] Recursive Queries in Microsoft SQL Server > 2008 > > Hi Arthur > > I think I recall that article. But wasn't that about a limited/fixed > number of sublevels? True recursion should just continue one level > down until no more levels are found, no matter how many levels. > > /gustav > > -----Oprindelig meddelelse----- > Fra: dba-sqlserver-bounces at databaseadvisors.com > [mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Arthur > Fuller > Sendt: 28. oktober 2013 16:34 > Til: Discussion concerning MS SQL Server > Emne: Re: [dba-SQLServer] Recursive Queries in Microsoft SQL Server > 2008 > > Gustav, > > Yes and no. Somewhere on TechRepublic there's an article by me that > discusses recursive SQL within a stored procedure. If you can't find > it, I have a copy in Word format that I could send you off-list, but > their search is pretty good. Try "recursion in t-sql". If that doesn't > work try searching for my name and that ought to find it. > > Anyway, you're right: The WITH AS (SELECT...) construct is > T-SQL not pure SQL. In essence, what you're doing is creating a > virtual temp table and then joining that to the real table (or view). > > And you're also wrong. In pure SQL it's quite common to join a table > or view to itself. One typical use of this technique is to find the > second-last item in a set (which you do by joining a set to itself but > the WHERE clause uses a "<" comparison rather than an "=". Combine > that with an ORDER BY ... DESC and you get the previous row. If that's > a little fuzzy, I'll supply an example, but I encourage you to ponder > it first. LOL. > > Arthur > > > On Mon, Oct 28, 2013 at 11:06 AM, Gustav Brock wrote: > > > Hi Arthur > > > > So the WITH .. AS isolates the inner part? > > Normally, in pure SQL, you can't let a query pull data from itself > > without getting a circular reference error or the like. > > > > /gustav > > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > -- Arthur _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From fuller.artful at gmail.com Tue Oct 29 10:30:02 2013 From: fuller.artful at gmail.com (Arthur Fuller) Date: Tue, 29 Oct 2013 11:30:02 -0400 Subject: [dba-SQLServer] Recursive Queries in Microsoft SQL Server 2008 In-Reply-To: <631CF83223105545BF43EFB52CB082959C5B26F71E@EX2K7-VIRT-2.ads.qub.ac.uk> References: <000e01ced3fc$d70e9700$852bc500$@cactus.dk> <57357820.43842273.1382986974189.JavaMail.root@cds002> <631CF83223105545BF43EFB52CB082959C5B26F71E@EX2K7-VIRT-2.ads.qub.ac.uk> Message-ID: Gustav and Martin, Since we're in tutorial mode, I feel that I should tell you a story. I was called in to optimize an Access + SQL Server app, and there was one lengthy procedure that acted as a wrapper for 9 separate SPs, each of which did a query and then joined its result set to another table, retrieving values from that table to include in the final result set, which was then updated. After analyzing the T-SQL for a while, I realized that each of the 9 SPs called precisely the same record set from the main table, then each joined to a table of immediate interest and did the relevant updates to the main table. In other words, the SELECT from the main table was being performed 9 times. Enter the fact that in SQL 2008 you can create a variable of type Table. I took the 9 SPs and created one large SP (basically just by copying all their code into a new SP. At the top I did the query from the main table (a date-range and only some of the columns, not complicated at all. But the thing is that I declared a variable of type Table and assigned its value as the result set of the date-range query. Then I modified the code in the copied T-SQL to refer to the variable, which is not at all complicated, all you do is locate the FROM clause, and substitute the name of the Table variable for the name of the actual table. The point is, 8 re-queries of the rather large table were eliminated. The query was called once, and its results stored in the Table variable, and then each block of code that was formerly a SP already had the results from the main table. The performance result was very gratifying: 40 minutes became 8 minutes. Not bad for a morning's work on a job executed twice a day. Note: This could have been optimized further in versions subsequent to SQL 2008, since subsequent versions allow the passing of table variables as a parameter. In that environment, I would return to the original layout, updating it by passing the Table variable created in the SP that wraps all the others. In other words... Parent SP: Declare myTable as (SELECT This, That FROM apothecary WHERE datesold .... etc.) Call SP1(myTable) Call SP2(myTable) etc. This actually was my first choice, but only then did I discover that 2008 did not support the passing of tables to SPs. That happened later. Anyway, the first version garnered a huge increase in performance, especially valuable when the task is executed twice a day. On Tue, Oct 29, 2013 at 5:46 AM, Martin Reid wrote: > Spot on Arthur. Like Stewart I have immediate need of this as well. > > Martin > > > From fuller.artful at gmail.com Tue Oct 29 10:33:28 2013 From: fuller.artful at gmail.com (Arthur Fuller) Date: Tue, 29 Oct 2013 11:33:28 -0400 Subject: [dba-SQLServer] Recursive Queries in Microsoft SQL Server 2008 In-Reply-To: References: <000e01ced3fc$d70e9700$852bc500$@cactus.dk> <57357820.43842273.1382986974189.JavaMail.root@cds002> <631CF83223105545BF43EFB52CB082959C5B26F71E@EX2K7-VIRT-2.ads.qub.ac.uk> Message-ID: Oops! That was air code. *Call* dates back to Access FEs. I'm going to leave it to you guys to check out BOL and learn how a SP can execute another SP. Arthur