The following example is for creating a simple insert stored procedure. You can run it through an explicit call from a host language program.
DROP PROCEDURE IF EXISTS `sp_students_INSERT_byPK` GO CREATE PROCEDURE sp_students_INSERT_byPK ( IN p_student_id INT(11) , IN p_password VARCHAR(15) , IN p_active_flg TINYINT(4) , IN p_lastname VARCHAR(30) , IN p_firstname VARCHAR(20) , IN p_gender_code VARCHAR(1) , IN p_is_on_staff TINYINT(4) , IN p_birth_dttm DATETIME ) BEGIN INSERT INTO students ( student_id , password , active_flg , lastname , firstname , gender_code , is_on_staff , birth_dttm ) VALUES ( p_student_id , p_password , p_active_flg , p_lastname , p_firstname , p_gender_code , p_is_on_staff , p_birth_dttm ) ; END GO
You will note that just like in a INSERT statement you do not have to use all of the columns available when creating a stored procedure. You must however populate all columnar data associated with the PK (primary key), and columns associated with unique indexes (note: there are exceptions to this, but they will not addressed here), and columns defined in the ddl as "NOT NULL".
To run the insert stored procedure you need to supply a value to the student_id variable as well as populate all required data. In this example I have included a cross section of columns for your reference, as well as the datatype associated with the columns in our SQL INSERT.
/*** IN p_student_id INT(11) IN p_password VARCHAR(15) IN p_active_flg TINYINT(4) IN p_lastname VARCHAR(30) IN p_firstname VARCHAR(20) IN p_gender_code VARCHAR(1) IN p_is_on_staff TINYINT(4) IN p_birth_dttm DATETIME ***/
CALL sp_students_INSERT_byPK ( 25 , 'mydogSpot1' , 1 , 'Bag' , 'James' , 'M' , 1 , '1942-10-11' ) GO
A few thing to point out regarding the code above. Datetime and character data is entered using single quoted string. Integer data is entered without quotes. I also included all columns that were defined as NOT NULL. I also included the password column which is part of a unique index. You will note that I did not include columns for some of the non-unique indexes (soc_sec_num, other_id_num, and driver_license_num). I did this intentionally to demonstrate that they are not required columns. Having said this, in the "real world" one would only put indexes on columns where the intent was to actually collect the data for that column. I just wanted to make a technical point here. The pragmatic point is that you would want to expose columns that are part of indexes.
I want to call you attention to the fact that all columns that are not referenced in the query get set to null. Also, if the schema had default values defined these would also get stored for that column when the rows gets inserted.
p_password = 'mydogSpot1' p_active_flg = '1' p_lastname = 'Bag' p_firstname = 'James' p_gender_code = 'M' p_birth_dttm = '1942-10-11 00:00:00'