Dts.Variables["TheCurrentDate"].Value = DateTime.Date;

That little snippet of code will store the current date into a variable named “TheCurrentDate”. This is straightforward and there’s absolutely nothing wrong with the approach, however, there’s a simpler way to fetch this information without the need of adding a whole control flow item for such a minute amount of work. It’s brilliantly simple, only requires the creation of a variable, and can be added in about 10 seconds:

1. Create new variable with Data Type = DateTime
1. Set property EvaluateAsExpression = True
2. Set property Expression = 

   DATEADD( "day", DATEDIFF( "day", (DT_DATE) "1900-01-01", @[System::StartTime]  ) , (DT_DATE) "1900-01-01" )

That’s it! The variable will contain the package start time with the time truncated, making it easier to compare dates directly. In fact, this method can be used to truncate the time portion of any DateTime Data Type. Simply replace @[System::StartTime] with another variable.

Want to know how it works? The inner DATEDIFF() function calculates the number of days since 1900. This value is supplied to the outer DATEADD() function, adding days forward from 1900, resulting in a DT_DBTIMESTAMP with the time rounded off. And we accomplished it with pure math—no messy string manipulation required! I borrowed the idea from the same expression in T-SQL: DATEADD(day, DATEDIFF(day, 0, getdate()), 0).

There’s one caveat to this: Because SSIS doesn’t have a native date-only variable type, the value technically contains the date at midnight. However, many tools—such as SQL Server—will implicitly convert to the requisite data type, making “2011-09-28 12:00:00 AM” equal to “2011-09-28″

• Attunity SSIS Oracle Connector v1.1
• After installation, you’ll need to enable the menu items in the Data Flow Source & Destination
• Create Data Flow Task
• Switch to Data Flow
• Pull the Toolbox out
• Right-click→Choose items…
• Activate the SSIS Data Flow Items tab
• Enable “Oracle Destination” and “Oracle Source”
• Oracle Instant Client Basic package
• Download and extract both 64-bit and 32-bit versions if you’re using a 64-bit OS
• Only need the 32-bit version if installing on 32-bit OS
• Installation location is up to you, but you’ll need to note it later. This tutorial assumes C:\oracle\ as the base location.
• For example, install the 64-bit package at “C:\oracle\instantclient_x64_11_2″ and the 32-bit package at “C:\oracle\instantclient_x86_11_2″

Once you have all the items installed, you’ll need to add a couple of registry keys with regedit so that the SSIS connector can find the Oracle Instant Client. Create the necessary keys and string values below where they don’t exist, updating files paths to point to where you extracted the items above (again, C:\oracle\ is assumed for this tutorial):

•  [HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE]
• New→String Value→Name = TNS_ADMIN→Value = C:\oracle\tnsnames.ora
• New→String Value→Name = ORACLE_HOME→Value
• For 64-bit OS: C:\oracle\instantclient_x64_11_2
• For 32-bit OS: C:\oracle\instantclient_x32_11_2
• [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ORACLE] (64-bit OS only)
• New→String Value→Name = TNS_ADMIN→Value = C:\oracle\tnsnames.ora
• New→String Value→Name = ORACLE_HOME→Value = C:\oracle\instantclient_x86_11_2

Windows Registry Editor Version 5.00
 
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ORACLE]
"TNS_ADMIN"="C:\\oracle\\tnsnames.ora"
"ORACLE_HOME"="C:\\oracle\\instantclient_x32_11_2"
 
[HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE]
"TNS_ADMIN"="C:\\oracle\\tnsnames.ora"
"ORACLE_HOME"="C:\\oracle\\instantclient_x64_11_2"

Windows Registry Editor Version 5.00
 
[HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE]
"TNS_ADMIN"="C:\\oracle\\tnsnames.ora"
"ORACLE_HOME"="C:\\oracle\\instantclient_x32_11_2"

This setup allows you the choice of either using the names defined in TNSNAMES.ORA at the location specified in the registry above OR specifying the server inline in the format of <server.name.trb:port/service>. For example: <servername.path.to.tld:1521/ORA10DEV> (without the angle brackets). That’s really it! The process is much more streamlined than it was just a short while ago. Two installations and a couple regedit tweaks and you should be all set!

What made sense for us was to be able to supply the name of a principal, a “like name” for the database, and the role that they should have. What the “like name” allows us to do is apply a permission to a series of databases based on name. For example: ideaexcursion1, ideaexcursion2, ideaexcursion3 can all be set by supplying the paramater ideaexcursion%. This increases the complexity by forcing us to use a cursor in the proc, but reduces the number of actions we need to manage.

exec dbo.pr_SetGroupPermissions
      @principal = 'domain\principalname'
    , @db_likename 'ideaexcursion%'
    , @addrole 'db_owner'

This snippet will—as you’ll soon see—give domain\principalname the db_owner role in any databases that match LIKE ideaexcursion%. Here’s the magic behind the stored procedure:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

create proc dbo.pr_SetGroupPermissions @principal sysname, @db_likename sysname, @addrole sysname, @printonly bit = 0
as
declare
	  @database sysname
	, @cmd nvarchar(max)
 
declare csr_dbname cursor for
select name from sys.databases where state = 0 and name like @db_likename
 
open csr_dbname
 
fetch next from csr_dbname
into @database
 
while @@fetch_status = 0
begin
 
	set @cmd = '
USE '+quotename(@database)+'
 
IF EXISTS (SELECT * FROM sys.server_principals WHERE name = N'''+@principal+''')
BEGIN
	IF NOT EXISTS (SELECT * FROM sys.database_principals WHERE name = N'''+@principal+''')
		CREATE USER '+quotename(@principal)+' FOR LOGIN '+quotename(@principal)+'
	ELSE
		ALTER USER '+quotename(@principal)+' WITH LOGIN = '+quotename(@principal)+'
 
	EXEC dbo.sp_addrolemember N'''+@addrole+''', N'''+@principal+'''
END
'
 
	print @cmd
	if @printonly = 0
		exec(@cmd)
 
	fetch next from csr_dbname
	into @database
 
end
 
close csr_dbname
deallocate csr_dbname

And here’s a few notes on what the code does:

• Line 1: Parameter declaration. Notice that there is an optional @printonly param if you’d like to see the resulting code, but not execute it
• Line 7-8: Set up the cursor. On line 8 is the trick that allows us to use a “like name” to simplify the rules. Also, note that we check for “state = 0″ in the predicate, which corresponds to those with a state of ONLINE. If we didn’t check this, we would potentially attempt to execute commands against databases in RESTORING, RECOVERING, RECOVERY_PENDING, SUSPECT, EMERGENCY, or OFFLINE states
• Line 18-30: The main code which will be evaluated and executed. There are several parts to it to accommodate a variety of situations:
  • Line 19: Switch context to the correct database, since we’re executing within the confides of dynamic SQL. Also, the name is qualified with quotename(), which means that it should not be qualified when being passed in
  • Line 21: Validate that the user or group exists, otherwise we will get an error when trying to set it. Since we’re concerning ourselves with permission to a database, and not an instance, we don’t bother creating a user if it doesn’t exist. This is probably smart from a security perspective
  • Line 23-24: Check if the principal exists within the specific database. If not, create the user
  • Line 26: If the user already exists, fix any mismatched SIDswith ALTER USER. This is the preferred way to fix mismatched a mismatched SIDwhich was previously handled by sp_change_users_login, which has since been deprecated
  • Line 28: Assume database login is not valid and add the user or group to the specified role
• Line 32:  Always print the commands to be executed
• Line 33-34: Execute the code, unless the @printonly parameter has been specified

There you have it. A proc that grants specific roles to a principal across your entire database instance.

select db_name() [database_name]
	, dbpm.name, dbpm.type_desc, dbpm.create_date, dbpm.modify_date
	, dbpr.name, dbpr.type_desc
from sys.database_role_members dbrm
left join sys.database_principals dbpm
	on dbrm.member_principal_id = dbpm.principal_id
left join sys.database_principals dbpr
	on dbrm.role_principal_id = dbpr.principal_id
order by
	dbpm.name, dbpr.name

This is handily fantastic and works well when you’re just managing access to a single database. What about if you want to audit logins for the entirety of the database instance? Unfortunately, we have to rely on database cursors to build a query and execute it. The concept is easy, but the details can be a little tricky to manage. Here’s what I came up with:

declare @cmd nvarchar(max) = '', @dbname sysname
 
declare csr_dbname cursor for
select quotename(name) from sys.databases where state = 0
 
open csr_dbname
 
fetch next from csr_dbname
into @dbname
 
while @@fetch_status = 0
begin
	set @cmd = @cmd + '
select '''+@dbname+''' [database_name]
, dbpm.name [principal_name], dbpm.type_desc [principal_type], dbpm.create_date [principal_create], dbpm.modify_date [principal_modify]
, dbpr.name [role_name], dbpr.type_desc [role_type]
from '+@dbname+'.sys.database_role_members dbrm
left join '+@dbname+'.sys.database_principals dbpm
	on dbrm.member_principal_id = dbpm.principal_id
left join '+@dbname+'.sys.database_principals dbpr
	on dbrm.role_principal_id = dbpr.principal_id
	union all
	'
 
	fetch next from csr_dbname
	into @dbname
 
end
 
close csr_dbname
deallocate csr_dbname
 
set @cmd = left(@cmd, len(@cmd) - 12)
 
exec(@cmd)

There are a couple hacky things in this solution that could be factored out, but I’m keeping it simple. Here’s the walkthrough:

• Line 1: Declare and initialize necessary variables. Note that we’re combining declaration and initialization in a single step. If you’re not using SQL Server 2008, you’ll have to separate the initialization with a distinct “set @cmd = ”” command
• Line 3-4: Declare the query which defines the cursor. On line 4, we limit state = 0, because otherwise we might get databases in restoring or offline mode. Additionally, QUOTENAME() is used to ensure the input is sanitized for string concatenation. If you wanted to limit the scope of your databases, do it here.
• Line 6-12: Standard cursor setup
• Line 13-23: Build the query we’ll eventually use to scan all databases. We inject the database name from the cursor into the query to three-part qualify it, effectively neutralizing the current database context. Also, there’s a “union all” at the end that we’ll need to take care of later on
• Line 25-31: Standard cursor tear-down
• Line 33: Chuck the last “union all” from the query, lest it be dangling and we receive a parse error. If we were targeting re-usability, it would be smart to put the “union all” in a separate variable, rather than calculating the length of a literal
• Line 35: Execute the  query. We could optionally print the results here, but they’re typically longer than what Management Studio will display before truncating

It’s all quite simple and easy to toss into a stored procedure if you want to audit on a regular basis. Setting up a SQL Server Agent job to run monthly and return the results in an email would be straightforward enough. One of the issues I ran into and did not address was the sorting, which you may have noticed is absent in the extended script. This could be rectified by using “exec insert” notation, thought the results aren’t always dependable.

Given a table with columns:
A: int, primary key, identity
B: int, not null

How can I set a default for column B to be the value in column A?

This is an interesting problem on a couple levels. First, a computed column won’t work, because we need the ability to arbitrarily update column B. We could program a trigger, but I prefer to avoid them when possible. Preferably, we could actualize the purpose of the DEFAULT option. Unfortunately, this isn’t immediately an apparent choice because SQL Server doesn’t allow you to reference a column in a DEFAULT specification. In fact, according to BOL, “Only a constant value, such as a character string; a scalar function (either a system, user-defined, or CLR function); or NULL can be used as a default.”

Fortunately, the column which we’re trying to set a default from had an identity property, and system functions dealing with identity values is the key to using the DEFAULT specification. First, a little code:

CREATE TABLE dbo.IdentDefault
(
	A int NOT NULL IDENTITY (1, 1) PRIMARY KEY,
	B int NOT NULL DEFAULT SCOPE_IDENTITY()
)
 
INSERT INTO dbo.IdentDefault DEFAULT VALUES
INSERT INTO dbo.IdentDefault DEFAULT VALUES
INSERT INTO dbo.IdentDefault DEFAULT VALUES
 
UPDATE dbo.IdentDefault SET B = 10 WHERE A = 1
 
SELECT * FROM dbo.IdentDefault

And the result:

A           B
----------- -----------
1           10
2           2
3           3

As you can see from the above result set, column B defaults to whatever column A contains, yet we can still update column B to whatever value necessary.

The Setup

• Windows 7 64-bit
• Visual Studio 2008
• SQL Server 2008 64-bit

The Process

1. Create a signing key (See also, How to: Create a Public/Private Key Pair)
   1. Open Visual Studio 2008 command Prompt – the regular command prompt will not work
   2. Change to a friendly directory: cd %userprofile%\Desktop
   3. Create the key file: sn -k key.snk
2. Sign the assembly – There are a few ways to do this, but I found this to be the easiest. If you want to sign it some other way, check out How to: Sign an Assembly with a Strong Name
   1. Right-click the Project
   2. Select “Properties”
   3. Navigate to the “Signing” tab
   4. Browse to strong name key file (which was created in the previous step)
   5. Recompile the project
3. Copy the re-compiled assembly to your GAC
   1. gacutil -i “C:\Path\to\CustomAssemblyName.dll”
4. Copy assembly to “%programfiles(x86)%\Microsoft SQL Server\100\SDK\Assemblies”
5. Add reference in script task. Repeat this for every Script Task you want to access this assembly from
   1. Right-click References
   2. Click “Add Reference…”
      

      Add Reference...

   3. On the .NET tab, scroll to find your assembly
   4. Press “OK”
   5. The Assembly should now appear under the References list
6. Add a reference to the assembly in code, at the top
   1. (C#) Using CustomAssemblyName;
   2. (VB.NET) Imports CustomAssemblyName
7. You should now have full access to the imported DLL

Caveats

This method works pretty well, but deployment isn’t exactly seamless – you’ll have to repeat this for each server and re-register & copy the DLL separately for any updates. Additionally, there is no way to globally add the assembly reference to the entire project or package. Instead, you’ll have to repeat step 6 (adding the reference) for every Script Task.

Steps

1. First, fire up Visual Studio (2005 or 2008 – it doesn’t matter).
2. Create a new project – name it something clever, like “RegEx”
3. After creating the project, you should be prompted to connect to a database where you’ll eventually want to deploy the project. This is completely optional and can be changed later.
4. Right-click the project name (“RegEx”) and choose Add → User-Defined Function
   

   Add User Defined Function

5. Name the file RegExMatch.
6. Paste the following code into that file
7. When done, simple build (Ctrl+Shift+B) and deploy (Right-click the project name (“RegEx”) → Deploy).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

using System;
using System.Data;
using System.Data.SqlClient;
using System.Data.SqlTypes;
using Microsoft.SqlServer.Server;
using System.Text.RegularExpressions;
 
public partial class UserDefinedFunctions
{
    [Microsoft.SqlServer.Server.SqlFunction(IsDeterministic = true, IsPrecise = true)]
    public static SqlString RegExMatch(SqlString expression, SqlString pattern)
    {
        if (expression.IsNull || pattern.IsNull)
            return SqlString.Null;
 
        Match match = new Regex(pattern.ToString()).Match(expression.ToString());
 
        return match.Success ? new SqlString(match.Value) : SqlString.Null;
 
    }
};

Code Explanation

• Line 1-6: Including necessary assemblies. The only item you need to add is line 6 – System.Text.RegularExpressions
• Line 11: We indicate the function requires 2 parameters, the input string and the regular expression to apply.
• Line 13-14: Check if either input string is NULL. If so, return NULL and do nothing else.
• Line 16: There’s a lot packed on this line, but essentially, it creates an object named match based on the results of the regular expression match operation.
• Line 18: Use the ternary operator to check if the match was a success. If so, return the matching string. Otherwise, return a NULL.

Examples

We’re going to use a simple regular expression to check for a valid US postal code (AKA Zipcode + 4):

^\d{5}(-\d{4})?$

This regular expressions checks for exactly 5 digits followed by an option group of hyphen and 4 more digits.

select
	  dbo.RegExMatch('90210','^\d{5}(-\d{4})?$')
	, dbo.RegExMatch('90210-1234','^\d{5}(-\d{4})?$')
	, dbo.RegExMatch('90210-','^\d{5}(-\d{4})?$')
	, dbo.RegExMatch('9021A','^\d{5}(-\d{4})?$')

And results:

90210	90210-1234	NULL	NULL

Other notes

If you need to change the target database, do so in the project’s properties:

1. Right-click the proeject name (“RegEx”) → Properties
2. Select the Database tab (2nd item from the bottom)
3. Click “Browse…” to create and test the connection string.
   

   Database Properties

Thanks to Jeff’s SQL Server Blog for the initial Regular Expression Replace code.

1. Download and install MySQL Connector/NET 6.0
2. Start a new Integration Services project in BIDS
3. Right-click in Connection Managers and create a new ADO.NET Connection

   

4. In the Provider dropdown, expand .Net Providers and select MySQL Data Provider. Press "OK"

   

5. Fill out the Server name, User name, Password and select the database name for the target MySQL server. Be sure to test the connection and press “OK”

   

6. Rename the connection to “MySQLDB”

   

7. Open up the Toolbox and drag a Data Flow Task from the toolbox onto the Control Flow surface
   

   Add Dataflow Task

8. Double-click the Data Flow Task to switch to the Data Flow view
9. Create a new variable, “MySQLResult” with the Data Type of Object. We will be using this as the final destination for the data, so we don’t need to connect to a file or database to store the data from this test
   

   MySQLResult Variable

10. Drag a new DataReader Source component onto the Data Flow surface
    

    Add DataReader Source

11. Double-click the DataReader Source to open the Advanced Editor. On the Connection Managers tab, select the previously-created MySQLDB connection
    

    DataReader Source Connection Managers

12. Switch to the Component Properties tab and enter the SQL query in the SqlCommand property. Note that the query must be compatible with MySQL syntax, not SQL Server.
    

    DataReader Source Component Properties

13. Switch to the Column Mappings tab to verify that the query is successful and the all the columns were pulled from the database. When done, press “OK”.
    

    DataReader Source Column Mappings

14. Create a new Recordset Destination by dragging it from the toolbox to the Data Flow surface
    

    Add Recordset Destination

15. Drag the green Data Flow Path from DataReader Source to Recordset Destination, so they connect
    

    Connect Source to Destination

16. Double-click the Recordset Destination to open its Advanced Editor
17. Under Custom Properties, select the dropdown for VariableName and select the variable we created before, User::MySQLResult
    

    Recordset Destination Component Properties

18. Switch to the Input Columns tab and select those columns that you want stored in the Recordset Destination. When complete, click “OK”
    

    Recordset Destination Input Columns

19. Right-click the green Data Flow Path and choose “Data Viewers…”
    

    Data Flow Path Data Viewers

20. Select “Data Viewers” from the left pane and click the “Add…” button
    

    Data Flow Path Editor

21. Under the General tab, select Grid and press “OK”
    

    Configure Data Viewer

22. Run the package
23. If you’ve done everything correctly, you should see a Data Reader Output Data Viewer window pop up with the contents of the query we specified earlier.
    

    Data Viewer Output

SQL Server Integration Services makes connecting to other systems very easy. The MySQL ADO.NET provider works well, but requires more configuration than a native Source component.

Actual employee structure to be flattened

This structure will act as our example for the Development Department. The Department Head (Employee 0) has asked for a report of all employees within each team of the development group. Notice that different groups have varying levels of depth. The Database team only has a Manager with two direct reports. The UI team is a single person. The Middle Tier group is much larger, with a Manager having two direct reports, and one of those employees having several employees beneath him. The requested report should group all employees, flattening the relationship to a single Manager, but excluding himself (since that would mean every employee would simply roll up to him). This “Desired Relationship” is represented below:

The desired result of the query

To recreate this scenario, I’m providing some code for both the setup and query. If you’re not familiar with Common Table Expressions, I would suggest that you familiarize yourself with the SQL Server BOL entry. The main concept you should understand to be able to adapt this to your own data is that for a CTE to act recursively, you need both an anchor and recursive query. I’ll explain their parts later.

First, let’s instantiate the tables and populate them with data:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

use tempdb
go
 
if object_id('dbo.Employees') is not null
	drop table dbo.Employees
go
 
create table dbo.Employees
(
	  EmployeeID int primary key
	, EmployeeName varchar(50) not null
	, ManagerEmployeeID int null
)
go
 
insert into dbo.Employees (EmployeeID, EmployeeName, ManagerEmployeeID)
select 0, 'Employee 0', null
union all
select 1, 'Employee 1', 0
union all
select 2, 'Employee 2', 0
union all
select 3, 'Employee 3', 0
union all
select 4, 'Employee 1.1', 1
union all
select 5, 'Employee 1.2', 1
union all
select 6, 'Employee 3.1', 3
union all
select 7, 'Employee 3.2', 3
union all
select 8, 'Employee 3.1.1', 6
union all
select 9, 'Employee 3.1.1.1', 8
go

This script will simply create the example employees table and populate it with data to relationally represent what is displayed in the first picture. Here are what the various lines accomplish:

• 1-2: Switch the database context to tempdb. Since the contents of tempdb are cleared upon service restart, we’re simply ensuring that this will be cleaned up eventually.
• 4-6: Check if dbo.Employees exists. If so, drop it.
• 8-14: Create a table to hold our example data.
• 16-36: Manually populate the example data. Note that we’re using a UNION ALL between the selects, so only a single INSERT occurs.

As for the query to manipulate this data, here is the actual CTE:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

-- Use a CTE to flatten an organization structure to each department
with AllMyChildren (ManagerEmployeeID, EmployeeID, GroupManagerID, EmployeeName, Depth)
as
(
	-- The anchor statement. This selects each department head
	-- The important part is to alias the original EmployeeID as the GroupManagerID
	select ManagerEmployeeID, EmployeeID, EmployeeID [GroupManagerID], EmployeeName, 0 [Depth]
	from dbo.Employees where EmployeeID in
		-- We want all employees 1 level below below a certain level, so we'll utilize a subquery to find them
		(
		-- Get EmployeeIDs that are children to their common parent
		select EmployeeID from dbo.Employees where ManagerEmployeeID = 0
		)
	UNION ALL
	-- The recursive statement which finds all employees under each department
	select pc.ManagerEmployeeID, pc.EmployeeID, amc.GroupManagerID, pc.EmployeeName, Depth + 1
	from dbo.Employees pc
	inner join AllMyChildren amc on pc.ManagerEmployeeID = amc.EmployeeID
)
-- The CTE is primed, but we still need to execute it with the statement below
select EmployeeName, GroupManagerID, Depth 
from AllMyChildren
order by GroupManagerID, Depth
-- Use the MAXRECURSION query hint to avoid default recursion limit of 100
OPTION (MAXRECURSION 0)

I’ve commented liberally, but I’ll go through this line-by-line to explain it in more detail.

• 2-4: Define the CTE (AllMyChildren) and the columns that it will output (ManagerEmployeeID, EmployeeID, GroupManagerID, EmployeeName, Depth)
• 7-8: This is the anchor statement. SELECT the fields we eventually want outputted. The key to this is that EmployeeID is being included a second time, but aliased as GroupManagerID.
• 10-13: This is a subquery in the WHERE condition of the anchor statement. Because we want to discard some levels (only the topmost level in our example), we need to tell the anchor to fetch all children whose parent EmployeeID is 0. Adjust this sub-query to affect at what level the teams should roll up to.
• 14-18: UNION ALL the anchor to the recursive portion of the CTE. The recursive part of the query is similar to the anchor in that it must SELECT similar columns. Notice that it again selects from dbo.Employees, but it also performs an INNER JOIN against the CTE, linking the EmployeeID and ManagerEmployeeID. This is what causes to recursion to occur. Additionally, we increment Depth by 1. The inclusion of the level is completely optional in the CTE, but may be helpful for reporting.
• 19: Close the CTE block. At this point, it is defined, but we have yet to execute it.
• 21-23: Perform a SELECT against the CTE to start it.
• 25: By default, recursion in Common Table Expressions is limited to 100 iterations. If you anticipate having more than 100 records, you’ll need to specify MAXRECURSION 0. When testing, you can limit it to any number up to 32,767 to prevent wild-running queries. Here – since this is tested and working – we specify “0″ for unlimited iterations.

And this is the result of the above query:

The tabular results of the query