Heh... judging from the number of forums you have this same article posted on, I'd say you have some work cut out for you in making a correction. ;-)
xp_DirTree actually takes 3 operands:
1. The path to a folder. This may be a UNC or drive path.
2. The number of levels below the path in the first operand. If missing, the default is "0" which equates to "all levels" which, as you know, can be terribly long. Levels above "0" operate as expected where Level 1 is the current directory only.
3. There's a third operand that most are simply not aware of. The default for this operand is "0" which means "only list directories". If this operand is set to any non-zero value, the output will return a 3rd column named "File". It should have been called "IsFile" because a "1" in this column means the "Subdirectory" column actually contains a file name instead of a folder name.
So, try running this and see what you get...EXEC Master.dbo.xp_DirTree 'C:\',1,1
Think of it as an xp_FileExists on steroids. You can also capture the output for processing using something like the following:CREATE TABLE #MyDir
RowNum INT IDENTITY(1,1) PRIMARY KEY CLUSTERED,
INSERT INTO #MyDir
(FolderFileName, Depth, IsFile)
EXEC Master.dbo.xp_DirTree 'C:\',1,1
SELECT * FROM #MyDir
Of course, the first operand may be contained in a variable without any dynamic SQL being necessary.
is pronounced ree-bar and is a Modenism for R
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Helpful Links:
How to post code problemsHow to post performance problemsForum FAQs