September 19, 2013 at 9:20 pm
Hello Everyone and Hello World
How should i use stored procedure in inserting in three tables? like this one...
i Have 3 tables namely Bio, Sex, and Status
*Bio
bioID
Firstname
middlename
lastname
sexID
statusID
*Sex
sexID
sex(Male or Female only)
*Status
statusID
status(Single or Married or Divorce only)
i have a code like this....
-----------------------------------------------------------------------
set ANSI_NULLS ON
set QUOTED_IDENTIFIER ON
go
-- =============================================
-- Author:<Author,,Name>
-- Create date: <Create Date,,>
-- Description:<Description,,>
-- =============================================
ALTER PROCEDURE [dbo].[SaveBiography]
@firstname varchar(50),
@middlename varchar(50),
@lastname varchar(50),
@sex varchar(50),
@status varchar(50),
@sexID int,
@statusID int,
@bioID int output
AS
BEGIN
SET NOCOUNT ON;
SET @firstname = LTRIM(RTRIM(@firstname))
SET @middlename = LTRIM(RTRIM(@middlename))
SET @lastname = LTRIM(RTRIM(@lastname))
SET @sex = LTRIM(RTRIM(@sex))
SET @status = LTRIM(RTRIM(@status))
IF EXISTS(SELECT * FROM Biography.dbo.Bio WHERE firstname = @firstname AND middlename = @middlename AND lastname = @lastname AND bioID <> @bioID)
BEGIN
RAISERROR ('[Error]Duplicate name', 16, 1)
RETURN
END
IF @firstname = ''
BEGIN
RAISERROR ('[Error]No first name', 16, 1)
RETURN
END
IF EXISTS (SELECT * FROM Biography.dbo.Bio WHERE bioID = @bioID)
BEGIN
UPDATE Bio SET firstname = @firstname, middlename = @middlename, lastname = @lastname, sexID = @sexID, statusID = @statusID WHERE bioID = @bioID
END
ELSE
BEGIN
IF @sex = 'Male'
BEGIN
@sexID = 1
END
ELSE
BEGIN
@sexID = 2
END
IF @status = 'Single'
BEGIN
@statusID = 1
END
ELSE IF @status = 'Married'
BEGIN
@statusID = 2
END
ELSE @status = 'Divorced'
BEGIN
@statusID = 3
END
INSERT INTO Bio(firstname,middlename,lastname, sexID, statusID ) VALUES (@firstname, @middlename, @lastname, @sexID, @statusID )
SELECT @bioID = SCOPE_IDENTITY()
END
END
-----------------------------------------------
and i'm getting this kind of error..
------------------------------------------------
Msg 102, Level 15, State 1, Procedure SaveBiography, Line 41
Incorrect syntax near '@sexID'.
Msg 102, Level 15, State 1, Procedure SaveBiography, Line 59
Incorrect syntax near '@statusID'.
Msg 102, Level 15, State 1, Procedure SaveBiography, Line 67
Incorrect syntax near '@statusID'.
Msg 102, Level 15, State 1, Procedure SaveBiography, Line 112
Incorrect syntax near 'END'.
--------------------------------------------------------------
Please Help me Lord:crying:
September 19, 2013 at 10:02 pm
Hi,
I think one problem is you forgot to say 'set'...
For example, this:
BEGIN
@statusID = 3
END
...should be this:
BEGIN
SET @statusID = 3
END
September 19, 2013 at 11:12 pm
Thanks you my friend....
yeah you are right...i forgot to put set...i put it already and it give me this error
--------------------------
Msg 102, Level 15, State 1, Procedure SaveBiography, Line 70
Incorrect syntax near '@status'.
what should i do?....
September 19, 2013 at 11:20 pm
what are you trying to do?
can you please post some sample data and what you want as output from that sample data?
_______________________________________________________________
To get quick answer follow this link:
http://www.sqlservercentral.com/articles/Best+Practices/61537/
September 19, 2013 at 11:24 pm
enriquezreyjoseph (9/19/2013)
Thanks you my friend....yeah you are right...i forgot to put set...i put it already and it give me this error
--------------------------
Msg 102, Level 15, State 1, Procedure SaveBiography, Line 70
Incorrect syntax near '@status'.
what should i do?....
Write
ELSE IF @status = 'Divorced'
......
Instead of this:
ELSE @status = 'Divorced'
_______________________________________________________________
To get quick answer follow this link:
http://www.sqlservercentral.com/articles/Best+Practices/61537/
September 19, 2013 at 11:36 pm
Thanks my friend you got it!!!
September 20, 2013 at 4:08 am
You should not be inserting into All three tables. You should be inserting data into one, the table named "Bio". The other two tables are list tables. Those tables would very rarely change once loaded.
With the code that you have shown, you would be much better off using MERGE instead of all of that antiquated code.
This code is a waste, since @FirstName is an input parameter that will not allow a NULL. And the front-end should be checking the values for blanks, not the database.
IF @firstname = ''
BEGIN
RAISERROR ('[Error]No first name', 16, 1)
RETURN
END
If that variable from the front-end gets all the way to the database with a blank space, you need to look at the code on the front-end.
The input parameters of
@sex varchar(50),
@status varchar(50)
Should be INT, not varchar(). You need to pass in the RowID, or IDENTITY of the values in the list table, not the actual value. What if you were passing in a country ID? There are just over 240 countries, would you have a huge CASE statement to figure out what ID the country name is? No, you should be passing in the RowID of the list table. That way, if there is a new country name, you do not have to go in all your database code and change an already huge, and very inefficient CASE statement, you simply add the new name to the list table, and the ID will be assigned.
I would never, ever combine my code like that. I have a page to pass in a new row, and a different page to update the existing code. And I have strict security around the page that allows updating. I do check to see if the row exists first, but then do nothing but fall out of the entire sproc returning the ID of the existing RowID. That will let the front-end know that the row already exists. I would never update said row like that.
But I suggest that you look into using MERGE if you want to do both in the same sproc.
Andrew SQLDBA
September 20, 2013 at 7:15 pm
Thanks andrew 🙂
September 21, 2013 at 10:48 am
AndrewSQLDBA (9/20/2013)
This code is a waste, since @FirstName is an input parameter that will not allow a NULL. And the front-end should be checking the values for blanks, not the database.
IF @firstname = ''
BEGIN
RAISERROR ('[Error]No first name', 16, 1)
RETURN
END
If that variable from the front-end gets all the way to the database with a blank space, you need to look at the code on the front-end.
I would recommend that you keep that code - relying on the front end to enforce domain constraints is a mistake. You should also have the column in the table declared
FirstName varchar(50) NOT NULL CHECK(LEN(FirstName) > 0)
since that's how domain constraints are expressed in T-SQL and you should want our tables to be in 1NF, which means the table definition must specify the domain of each attribute. Since the NULL values and zero length strings are not in the domain of this attribute, the table definition should say so.
Of course it's a good idea to have the front end check these things too - it can usually give a quicker and better response to a user who makes a mistake that it detects than if it lets the mistake through for the database to detect. But that doesn't absolve the database from responsibility for data integrity.
Tom
September 22, 2013 at 6:42 pm
L' Eomot Inversé (9/21/2013)
AndrewSQLDBA (9/20/2013)
This code is a waste, since @FirstName is an input parameter that will not allow a NULL. And the front-end should be checking the values for blanks, not the database.
IF @firstname = ''
BEGIN
RAISERROR ('[Error]No first name', 16, 1)
RETURN
END
If that variable from the front-end gets all the way to the database with a blank space, you need to look at the code on the front-end.
I would recommend that you keep that code - relying on the front end to enforce domain constraints is a mistake. You should also have the column in the table declared
FirstName varchar(50) NOT NULL CHECK(LEN(FirstName) > 0)
since that's how domain constraints are expressed in T-SQL and you should want our tables to be in 1NF, which means the table definition must specify the domain of each attribute. Since the NULL values and zero length strings are not in the domain of this attribute, the table definition should say so.
Of course it's a good idea to have the front end check these things too - it can usually give a quicker and better response to a user who makes a mistake that it detects than if it lets the mistake through for the database to detect. But that doesn't absolve the database from responsibility for data integrity.
Thanks Tom...you are so great :-)..cheers!!!
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply