Inserting comma seperated values

Question

I created a stored procedure that creates an order_id. Using this id, the products and their pricetag are inserted. Hereafter the garnishes are inserted for each product.
Creating an order id and inserting the products and their pricetag are working. The problem is at the inserting of garnishes. 
The data is received by parameters, and I have also created a user defined type: where garnishId holds the comma seperated ids.
CREATE TYPE [dbo].[ppg] AS TABLE(
[ProductId] [int] NULL,
[PriceId] [int] NULL,
[garnishId] [VARCHAR](MAX) NULL
this is the stored procedure:
ALTER PROCEDURE [dbo].[sp_create_order]
(@userId uniqueidentifier, @productPriceGarnishes dbo.ppg READONLY, @comment varchar(250))
AS
BEGIN
DECLARE @orderId int
DECLARE @orderDetailId int
INSERT INTO orders (user_id, confirmed,comment) values(@userId,0,@comment);
--Select last inserted PK
SELECT @orderId=SCOPE_IDENTITY()
-- insert products and price tag using @orderId
INSERT INTO order_detail (order_id, product_id,price_id)
SELECT @orderId, p.ProductId,
p.PriceId
FROM @productPriceGarnishes p
SELECT @orderDetailId=SCOPE_IDENTITY()
-- insert garnishes using the orderDetailId
INSERT INTO order_detail_garnish (order_detail_id,garnish_id)
SELECT @orderDetailId, (SELECT * FROM SplitDelimiterString(p.garnishId))
FROM @productPriceGarnishes p
END
RETURN @orderId
I found a function that splits the string by a delimiter in this website:
http://www.codeproject.com/Tips/586395/Split-comma-separated-IDs-to-ge
Where you can retrieve the ids by this query:
(SELECT * FROM SplitDelimiterString(p.garnishId)
The problem is that I don't know how to add these ids with their corresponding orderDetailId, after each product is added.

Answer 1

Unfortunately it appears you assume too much.  Presumably the reason you chose to define @productPriceGarnishes as a table is to support the creation of multiple rows. And you use these rows to insert into the order_detail table which has an identity
column as the primary key (again, presumably).  So the question then becomes how do you get the identity values for ALL of the inserted rows?  You can't do that with SCOPE_IDENTITY - your code currently is designed with the assumption that there
is only one row to be inserted.  To work around that limitation you need to use the output clause (examples can be found by searching). 
Next comes another problem.  How do you know which identity value is assigned to which row of your table variable during the insert?  You need some sort of natural key to associate the inserted rows with the rows in the table variable.  Do
you have one?  Before you think you do, you need to think about what restrictions are placed on the content of the table variable (if any).  Is it possible to have multiple rows with the same values for ProductId and PriceId?  Do not assume
- you need to be certain that this is or is not a possibility.
Assuming that the rows are unique (which simplifies things greatly), you associate the inserted order_detail rows to the table variable via something like:
select ... from @ins_detail as ins inner join @productPriceGarnishes as ppg
on ins.ProductId = ppg.ProductId and ins.PriceId = ppg.PriceId
Note that @ins_detail is a table variable that you would declare and populate via the output clause. It will contain the identity values for each row that you inserted.  With that, you can then generate the rows that you need to insert into the garnish
table by applying the results of your splitter function.  Which is a step that I'll skip for now since you have much reading and work to do. 
Now some last comments.  I am suspicious of a column named PriceId.  That is not a good sign - price is an attribute of something and not the basis of a relationship between tables.  The use of identity columns (especially as primary keys)
can be a problem - and this is one good example.  Based on what I've just written and its assumptions, the natural key for order_detail is (order_id, product_id, price_id) - why do you need an identity column?  Again, searching will find past
discussions about identity columns and their usage.