Throwing Custom Errors in MySQL store procedures - mysql

Question

I'm playing around with MySQL stored procedures and I need a little help wrapping my head around some things. Below I'm attempting to;
1) Check if the student_id exist in the database and if it does then display "alumni already exist"
2) Check to see if the department and degree parameter entered don't exist and if it doesn't, then display "_ does not exist" (side note : these two columns are foreign keys)
Right now, my IF statement doesn't work and throws arbitrary errors. (ex. student_id doesn't exist in table but the error "Alumni Exist Already" is thrown, this is one of many)
I'd like to know what I'm doing wrong. Also, If the way I'm approaching this makes sense and if it doesn't, what's a more pragmatic way of going about this?
Thanks
DELIMITER //
DROP PROCEDURE IF EXISTS sp_add_alumni//
CREATE PROCEDURE sp_add_alumni (
IN student_id INT(20),
IN first_name VARCHAR(255),
IN last_name VARCHAR(255),
IN street VARCHAR(255),
IN city VARCHAR(255),
IN state VARCHAR(2),
IN zip_code VARCHAR(15),
IN email VARCHAR(255),
IN telephone VARCHAR(22),
IN degree VARCHAR(255),
IN department VARCHAR(255)
)
BEGIN
DECLARE studentID INT(20);
DECLARE departmentVAL VARCHAR(255);
DECLARE degreeVal VARCHAR(255);
DECLARE EXIT HANDLER FOR SQLWARNING
BEGIN
ROLLBACK;
SELECT 'ALUMNI INSERT HAS FAILED';
END;
SET studentID = student_id;
SET departmentVal = department;
SET degreeVal = degree;
IF EXISTS (SELECT 1 FROM alumni WHERE student_id = studentID ) THEN
SELECT 'ALUMNI ALREADY EXISTS';
ELSEIF NOT EXISTS (SELECT 1 FROM valid_departments WHERE UCASE(department) = UCASE(departmentVal)) THEN
SELECT 'DEPARTMENT DOES NOT EXISTS';
ELSEIF NOT EXISTS (SELECT 1 FROM valid_degrees WHERE UCASE(degree) = UCASE(degreevVal)) THEN
SELECT 'DEGREE DOES NOT EXISTS';
ELSE
SELECT 'ALUMNI ADDED';
END IF;
START TRANSACTION;
INSERT INTO alumni (student_id, pwd ,first_name, last_name, street, city, state, zip_code, email, telephone, degree, department, role_id, donation_total) VALUES (student_id, NULL ,first_name, last_name, street, city, state, zip_code, email, telephone, degree, department, 1, 0.00);
COMMIT;
END//

Answer 1

I'd like to know what I'm doing wrong.
As documented under Restrictions on Stored Programs:
Name Conflicts within Stored Routines
The same identifier might be used for a routine parameter, a local variable, and a table column. Also, the same local variable name can be used in nested blocks. For example:
CREATE PROCEDURE p (i INT)
BEGIN
DECLARE i INT DEFAULT 0;
SELECT i FROM t;
BEGIN
DECLARE i INT DEFAULT 1;
SELECT i FROM t;
END;
END;
In such cases, the identifier is ambiguous and the following precedence rules apply:
A local variable takes precedence over a routine parameter or table column.
A routine parameter takes precedence over a table column.
A local variable in an inner block takes precedence over a local variable in an outer block.
The behavior that variables take precedence over table columns is nonstandard.
In your case student_id is a routine parameter and studentID is a local variable; therefore (given the precedence rules above) the filter criterion WHERE student_id = studentID is comparing those two things with eachother and at no time is inspecting a table column.
Since the local variable was set to the value of the routine parameter, this filter always evaluates to true.
You could avoid this either by using different names for your parameters/variables, or else by qualifying your column reference with a table prefix:
WHERE alumni.student_id = studentID
Also, If the way I'm approaching this makes sense and if it doesn't, what's a more pragmatic way of going about this?
Define suitable UNIQUE and foreign key constraints, then attempts to insert invalid data will fail without you explicitly having to check anything:
ALTER TABLE alumni
ADD UNIQUE KEY (student_id), -- is this not already a PRIMARY KEY ?
ADD FOREIGN KEY (department) REFERENCES valid_departments (department),
ADD FOREIGN KEY (degree ) REFERENCES valid_degrees (degree )
;
To make the foreign keys use a case-insensitive lookup, ensure that the respective columns use a case insensitive collation.
Note the restrictions to which foreign keys are subject in the article linked above.