May 2, 2018 at 4:17 pm
I have a 4 level job explosion of shortage parts where the first level sometimes has multiple entries. How do I write the recursive SQL string so it explodes each line individually? Or is it the same as a any recursive approach?
In the example attached I want it to look like the following between the Parent Job and the PO shortage columns.
--1
----2
------3
--1
--1
----2
--1
----2
------3
etc...
Right now it looks like this:
--1
--1
--2
--2
--2
--3
etc...
I don't need to add levels because they are already here in this dataset and I can use them. Is there an easy query that will solve this?
Thanks!
Ross
May 2, 2018 at 4:56 pm
If you could post some readily consumable data (see the first link in my signature line below under "Helpful Links" for how to do that), I'd be happy to scribe a bit of code that would demonstrate this along with the expected sort order.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 2, 2018 at 6:22 pm
--===== If the test table already exists, drop it
IF OBJECT_ID('TempDB..#mytable','U') IS NOT NULL
DROP TABLE #mytable
What I am trying to do is start with Level 1 and create a recursive relationship by following the relationship of the SUPPLYJOB on the current line be the PARENTJOBNUM of the next level, if there is one. Otherwise, show the next level 1, etc.
Thanks for the help post better and for considering a solution. I really appreciate it.
Regards,
Ross
May 2, 2018 at 6:31 pm
Having a look now... thanks for taking the time to make the data readily consumable.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 2, 2018 at 8:41 pm
First, what you've asked for is to determine the hierarchy of a "forest", meaning that it has more than one root and, therefor, more than 1 tree.
The type of hierarchy you have is called an "Adjacency List", which a lot of people refer to as a "Parent/Child" hierarchy. In this case, the SupplyJob column is the child and contains the required unique job numbers.
The following code will resolve the hierarchy for you. I recalculated the level for two reasons. First, to demonstrate that it's correctly calculated by you comparing the hLevel column I calculated with the Level column that you provided and, second, so that you wouldn't actually have to rely on someone else's code being correct. See the comment in the code about this.
WITH cteRoots AS
(
SELECT hLevel = 1
,hPath = CONVERT(VARBINARY(4000),CONVERT(BINARY(4),CONVERT(INT,ISNULL(SupplyJob,'9999999'))))
,*
FROM #mytable
WHERE [Level] = 1 --Would be better if this were WHERE ParentJobNumber = '012582' so you don't rely on someone else's code being right
UNION ALL
SELECT hLevel = cte.hLevel + 1
,hPath = CONVERT(VARBINARY(4000),cte.hPath + CONVERT(BINARY(4),CONVERT(INT,ISNULL(tbl.SupplyJob,'9999999'))))
,tbl.*
FROM #mytable tbl
JOIN cteRoots cte
ON tbl.ParentJobNumber = cte.SupplyJob
)
SELECT *
FROM cteRoots
ORDER BY hPath
;
For more information on how this all works, especially how the hPath (Hierarchical Path) column works, please see the following article. It also explains how to create Nested Sets, which is another hierarchical structure that results in nasty fast queries.
http://www.sqlservercentral.com/articles/Hierarchy/94040/
--Jeff Moden
Change is inevitable... Change for the better is not.
May 2, 2018 at 9:17 pm
Wow, Jeff. That is awesome and I so appreciate it! It works perfectly and I learned something new.
Thank you!
Ross
May 2, 2018 at 9:30 pm
Great. Thanks for the feedback, Ross.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 11, 2018 at 7:03 am
Hi Jeff,
I ran in to a little wrinkle in this line:
hPath = CONVERT(VARBINARY(4000),CONVERT(BINARY(4),CONVERT(INT,ISNULL(SupplyJob,'9999999'))))
My Supply Job Number is often a string and it gives me the "Conversion failed when converting the varchar value 'I19RU' to data type int." error.
How would I edit this final chunk to preserve the sorting you have laid out?
Thanks,
Ross
May 11, 2018 at 7:14 am
ross.hughes - Friday, May 11, 2018 7:03 AMHi Jeff,I ran in to a little wrinkle in this line:
hPath = CONVERT(VARBINARY(4000),CONVERT(BINARY(4),CONVERT(INT,ISNULL(SupplyJob,'9999999'))))
My Supply Job Number is often a string and it gives me the "Conversion failed when converting the varchar value 'I19RU' to data type int." error.
How would I edit this final chunk to preserve the sorting you have laid out?
Thanks,
Ross
What is the maximum number of characters that the Supply Job Number can be?
--Jeff Moden
Change is inevitable... Change for the better is not.
May 11, 2018 at 7:17 am
14
May 11, 2018 at 7:23 am
Hmmm.... is there an integer column on the original supply job table that acts like a surrogate key for the Supply Job Number?
--Jeff Moden
Change is inevitable... Change for the better is not.
May 11, 2018 at 7:41 am
I've not tested it because I'm on my way to work but I believe this will get you to where you want to be with the character based Supply Job Numbers. It's not quite as efficient as working with INTs converted to a BINARY(4) but should work reasonably well. It works on precisely the same principles as before, just using a different fixed-length datatype.
WITH cteRoots AS
(
SELECT hLevel = 1
,hPath = CONVERT(VARCHAR(8000),CONVERT(CHAR(14),ISNULL(SupplyJob,'ZZZZZZZZZZZZZZ')))
,*
FROM #mytable
WHERE [Level] = 1 --Would be better if this were WHERE ParentJobNumber = '012582' so you don't rely on someone else's code being right
UNION ALL
SELECT hLevel = cte.hLevel + 1
,hPath = CONVERT(VARCHAR(8000),cte.hPath + CONVERT(CHAR(14),ISNULL(SupplyJob,'ZZZZZZZZZZZZZZ'))))
,tbl.*
FROM #mytable tbl
JOIN cteRoots cte
ON tbl.ParentJobNumber = cte.SupplyJob
)
SELECT *
FROM cteRoots
ORDER BY hPath
;
--Jeff Moden
Change is inevitable... Change for the better is not.
May 11, 2018 at 8:02 am
Okay, thanks. That sets me in the in a direction.
I am getting an error 'Incorrect syntax near '.' on this but will work with it to see if i can get it to work.
Thanks, Jeff.
Ross
May 11, 2018 at 8:26 am
That looks like it is working, Jeff. There was only an extra parenthesis on the second line change.
Again, I really appreciate your help and have a better idea of what you are doing now.
Regards,
Ross
May 11, 2018 at 4:28 pm
ross.hughes - Friday, May 11, 2018 8:26 AMThat looks like it is working, Jeff. There was only an extra parenthesis on the second line change.Again, I really appreciate your help and have a better idea of what you are doing now.
Regards,
Ross
Glad to help. Thank you for the feedback.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply