CREATE PROCEDURE sp_insertEmployee
(
@Ename VARCHAR(100),
@Designation VARCHAR(100), --Length?
@Eno INT OUTPUT
)
AS
BEGIN --Procedure
INSERT Employee
(
Ename VARCHAR(100),
Designation VARCHAR(100) --??
)
VALUES
(
@Ename,
@Designation
)
SET @Eno = SCOPE_IDENTITY()
END --Procedure
------------------------------
When you execute this procedure from the procedure that inserts the
record in the cross-reference table between department and employee,
call it like so.
EXEC sp_insertEmployee @Ename, @Designation, @Eno OUTPUT
Alternately, you can also have the sproc RETURN the @Eno, instead of
having it as an OUTPUT parameter.
CREATE PROCEDURE sp_insertEmployee
(
@Ename VARCHAR(100),
@Designation VARCHAR(100) --Length?
)
AS
BEGIN --Procedure
INSERT Employee
(
Ename VARCHAR(100),
Designation VARCHAR(100) --??
)
VALUES
(
@Ename,
@Designation
)
RETURN SCOPE_IDENTITY()
END --Procedure
--------------
And to execute it you would do the following from the other sproc...
EXEC @Eno = sp_insertEmployee @Ename, @Designation
Also, it used to be the case that stored procedures named with sp_
were reserved. It was an issue with SQL Server 2000. I don't know if
that still a concern with SQL Server 2005, as I just don't do it
anymore. You might want to verify that it's not still an issue if you
stick with this sp_ prefix as your naming convention. My hunch is
that it still is a performance issue that will cause your sproc to be
recompiled on every execute. Here's an article on the history. I
can't imagine that SQL Server wouldn't still take advantage of the
performance gain for it's own system stored procedures by continuing
to make this assumption.
http://www.sqlmag.com/Articles/Artic...3011.html?Ad=1
Yes, apparently it's still an issue in MS SQL Server 2005 from this
source:
http://www.codeattest.com/blogs/mart...edures-is.html